r420 noch dieses jahr mit ps/vs 3.0 [Archiv]

ShadowXX

2003-06-13, 15:00:18

@Leonidas

das Problem was wir haben ist glaube ich mehr das keiner so genau weiss was der r420 für ein Chip ist??

Weiterentwicklung des 360->390->420??

oder doch wie bei FUAD eine Neuentwicklung??

Und was viel wichtiger ist: Ist der dort erwähnte r420 auch noch der r420 der vor ein paar Wochen schonmal durch die Foren geisterte.
Definitive Namensgebung scheint bei ATI momentan nicht so die Priorität zu sein...

Ich könnte mir durchaus vorstellen, dass ATI nach nv's Ankündigungen(nv40 dieses Jahr mit shadern nach 3.0) jetzt viellecht doch die 3.0'er Shader 'einbaut' (bzw. einen anderen Chip einfach zum r420 macht...den soweit ich weiss sollte der 420'er eigntlich nur ein nochmals Aufgebohrter r350(r390) werden...laut FUAD aber jetzt eine Neuentwicklung....

J.S.Shadow

Endorphine

2003-06-13, 15:00:44

Naja, der INQ ist in vielerlei Hinsicht nicht viel mehr als ne Gerüchteküche :)

Bei News (oder sollte man sagen "Rumors"? :D) rund um Intel und AMD ist der INQ aber oft erstaunlich treffsicher.

Bei Grafikkarten - äääh, na, ihr wisst schon ;)

Nur mal so als Beispiel -> http://www.theinquirer.org/02040201.htm ;D

mapel110

2003-06-13, 16:17:18

Original geschrieben von Endorphine
Naja, der INQ ist in vielerlei Hinsicht nicht viel mehr als ne Gerüchteküche :)

Bei News (oder sollte man sagen "Rumors"? :D) rund um Intel und AMD ist der INQ aber oft erstaunlich treffsicher.

Bei Grafikkarten - äääh, na, ihr wisst schon ;)

Nur mal so als Beispiel -> http://www.theinquirer.org/02040201.htm ;D

das war aber nicht FUAD

Endorphine

2003-06-13, 17:16:06

Original geschrieben von mapel110
das war aber nicht FUAD Nö, noch schlimmer, in der News stimmte wirklich gar nichts. Und ich verfasste damals sogar noch ne News zu diesem Gerücht :sulkoff:

zeckensack

2003-06-13, 17:22:46

Original geschrieben von Endorphine
Nö, noch schlimmer, in der News stimmte wirklich gar nichts.Nicht nur, daß es sich nicht als die Wahrheit herausstellte, dieses 'Stück Schrift' ist von vorne bis hinten Blödsinn.
Wir erinnern uns:
Ein Grafikchip habe acht Pipelines, und gleichzeitig zwei Pixelshader ?-)
Die Gf4Ti hat laut diesem Erguß gar nur einen Pixelshader. Bei vier Pipelines ist dies erstens unwahrscheinlich, zweitens nachgewiesenermaßen falsch.
Und der Witz schlechthin: 8*4 = 24 :|

Also wirklich :eyes:

Und ich verfasste damals sogar noch ne News zu diesem Gerücht :sulkoff: Schäm dich ;)

seahawk

2003-06-13, 19:48:10

Original geschrieben von Demirug
:cop: FUAD :cop:

Warten wir mal ab ob noch eine Bestätigung aus einer zuverlässigernen Quelle kommt. Ich würde mich freuen wenn es wirklich so kommen würde habe aber Zweifel.

Was ich nicht glaube da - :cop: FUAD :cop: (nicht mal die typischen ATI Infoquellen by Beyond 3D sagen sowas)

Ailuros

2003-06-14, 02:47:37

Original geschrieben von mapel110
http://www.theinquirer.net/?article=10001
da :)

da kommen dann wohl beide grossen hersteller zur selben zeit auf den markt. gott, wird das spannend :D

/edit
paperlaunch im november. auslieferung Q1/2004.

*raeusper* da waere ich seeeeehr enttaeuscht wenn es NUR 2 sind :D

Salvee

2003-06-16, 00:38:07

Original geschrieben von seahawk
Was ich nicht glaube da - :cop: FUAD :cop: (nicht mal die typischen ATI Infoquellen by Beyond 3D sagen sowas)

Hehe, MuFu selbst hat bei FUAD nachgefragt, und dieser ist sich zu 100% sicher, dass VS/PS3.0 an Bord sind :)
Wenn er wenigstens 99,9% gesagt hätte, aber 100%, naja...

http://www.rage3d.com/board/showthread.php?s=&threadid=33692195&perpage=20&pagenumber=3

Edit : :cop:

Ailuros

2003-06-16, 03:34:24

Also entschuldigt mal aber ich hab das Geruecht dass ATI tatsaechlich ohne PS/VS3.0 naechsten Fruehling dasteht schon eine geraume Zeit zuvor bezweifelt.

Mufu und Co. waren bis jetzt aeusserst genau mit ihren "Spekulationen"; aber da das Bild bei ATI und den Leuten die gerne nach aussen "off the record" plaudern eher trueb ist und nichts genaues gesagt wird was das Thema Shader3.0 betrifft, warte ich lieber ab bis sie das Ding (wie immer es auch heissen wird) ankuendigen.

Obwohl irrelevant, ich wurde vor dem R200 Release versichert, dass dieser Multisampling haben wird.... go figure heh....

Exxtreme

2003-06-16, 03:44:31

Original geschrieben von Ailuros
Obwohl irrelevant, ich wurde vor dem R200 Release versichert, dass dieser Multisampling haben wird.... go figure heh....
Das Teil hat tatsächlich kaputte MSAA-Einheiten. ATi hat diese dann für SSAA missbraucht. Leider funktionierten diese auch nicht richtig wenn Fog eingeschaltet war, so daß hier wiederum auf das Standard-SSAA zurückgegriffen wurde.

P.S. Fragt mich lieber nicht woher ich das weiss... ;)

stickedy

2003-06-16, 04:21:19

Ich kann mir nicht vorstellen, dass es sich ATI leisten kann, Ende des Jahres ohne PS/VS-Shader 3.0 dazustehen wenn NVidia und PowerVR welche haben!
Das wäre marketingtechnisch gesehen Wahnsinn!!

Ich frage mich auch, warum sie das Teil R420 nennen, wenn nix dramtisches im Vergleich zur 3xx-Serie geändert hat!

Warten wir doch einfach mal ab...

Ailuros

2003-06-16, 04:22:20

Ich kann´s nur bestaetigen; nur aeussere ich mich sehr selten ueber solche Kleinigkeiten. Es gab mehrere Bugs in der Hartware als nur diesen, aber wenn ich da die Klappe aufgemacht haette, muesste ich wohl jetzt genauso gemein mit der NV3x Serie sein (ich hoffe dass jetzt nicht ploetzlich beider Seiten fans ploetzlich darueber ueberschnappen).

Wie dem auch sei als man mir sagte dass R300 MSAA haben wird, habe ich nur gelacht, genauso ueber die Behauptung dass sie zumindest zweimal so schnell sein wird wie NV25, oder dass sie auf 325MHz mit 107M Transistoren steigen koennen usw usw.

Ich glaub seither gar nichts mehr bis es wirklich angekuendigt wird (also darf ich wohl R300/SSAA erst gar nicht erwaehnen *hust*) ;)

seahawk

2003-06-16, 08:06:41

Von Mufu bei Rage3D:

"Interesting that Fuad thinks R420 is fully PS/VS 3.0 compliant. I wrote to him about this (there's a first time for everything, lol) and he said he is 100% sure of it. I would be very suprised if that is the case. Seems like too big a change to engineer into R3x0."

Wobei, es schon schön wäre, dann würde so eine R420 meine R300 ersetzen...

Gast

2003-06-16, 09:10:05

Original geschrieben von Exxtreme
Das Teil hat tatsächlich kaputte MSAA-Einheiten. ATi hat diese dann für SSAA missbraucht. Leider funktionierten diese auch nicht richtig wenn Fog eingeschaltet war, so daß hier wiederum auf das Standard-SSAA zurückgegriffen wurde.

P.S. Fragt mich lieber nicht woher ich das weiss... ;)

Hab ich mir schon fast gedacht.

ABER: Warum haben die Stinkefinger bei ATi das Problem nicht wenigstens bei dem RV250-Chip behoben? Die R9000/Pro - Karten wären mit MSAA ( und dazu sogar Rotated Grid ) den MX4-Karten weit vorraus gewesen. Selbst die FX5200 - Karten hätten dann ein wesentlich größeres Problem (will ich AF+DX9 oder gutes-AA und höhere Geschwindigkeit). Hat sich ATi also selbst ein Bein gestellt.

mapel110

2003-06-16, 09:32:10

neue designs kosten auch immer kohle.

egal ob da "nur" nen kleiner bug gefixt wurde oder nicht.

Exxtreme

2003-06-16, 09:38:24

Original geschrieben von mapel110
neue designs kosten auch immer kohle.

egal ob da "nur" nen kleiner bug gefixt wurde oder nicht.
So sieht's aus. Bei einer High-End-Karte hätte es sich wohl gelohnt, die RV250 ist aber eher ein Mid-Range-Chip gewesen. Jetzt ist dieser nur noch Low-End.

Exxtreme

2003-06-16, 09:57:31

Hier mal ein Bildchen des R420-Cores:

http://www.dodstudios.net/uploads/uploads/ATi-Core-R420.jpg

nagus

2003-06-16, 10:09:59

Original geschrieben von Exxtreme
Hier mal ein Bildchen des R420-Cores:

http://www.dodstudios.net/uploads/uploads/ATi-Core-R420.jpg

:cop: PHOTOSHOP :cop:

Exxtreme

2003-06-16, 10:12:45

Original geschrieben von nagus
:cop: PHOTOSHOP :cop:
Ich weiss. ;)

Das Bild soll sich angeblich über's ganze Netz verbreiten.

StefanV

2003-06-16, 11:03:36

Original geschrieben von Exxtreme
So sieht's aus. Bei einer High-End-Karte hätte es sich wohl gelohnt, die RV250 ist aber eher ein Mid-Range-Chip gewesen. Jetzt ist dieser nur noch Low-End.

Tjo, schade, daß ATI den R200 Refresh, den es ja angeblich geben sollte, gecancelt hat...

Demirug

2003-06-16, 11:18:54

nana Exxtreme wir wollen doch keine Fehlinformationen verbreiten.

Ich habe mal ein Bild des echten R420 angehängt. Kein gutes Bild aber mehr kann man im Moment nicht bekommen.

EDIT: PS: Die zwei dunkleren Flächen rechts sollen übrigens zwei 400 MHz RLDRAM Chips mit jweils 36 MByte Speicher sein. Primär sollen darin gespeichert werden (solange Platz ist) Hir-Z Buffer, Z-Buffer, Framebuffer, Texturen die für Render2Texture vorgesehen sind. Die RLDRAM Chips sollen im verhältniss zur DDR-I und DDR-II eine viel bessere Netto-Bandbreite haben.

Wers glaubt ist selber schuld

nagus

2003-06-16, 12:14:42

Original geschrieben von Demirug
nana Exxtreme wir wollen doch keine Fehlinformationen verbreiten.

Ich habe mal ein Bild des echten R420 angehängt. Kein gutes Bild aber mehr kann man im Moment nicht bekommen.

sehr lustig *LOL*

Spake

2003-06-16, 12:25:32

imo sieht der ganauso aus wie der core des r300
das einzige was bei einem corebild interressant sein kann sind die "eingravierungen" wenn man sie entziffern kann ;)

im übrigen scheint es ja so als ob der R420 dochj einiges mehr trans als der R300 hat womit ich dann nicht PS/VS3.0 auschließe :?

MadManniMan

2003-06-16, 14:08:26

Original geschrieben von Demirug
Wers glaubt ist selber schuld

du hast zuviel zeit ?-)

MadManniMan

2003-06-16, 14:14:14

Original geschrieben von MadManniMan
du hast zuviel zeit ?-)

da fällt mir ein... hatte ich auch mal :D

Spake

2003-06-16, 16:30:19

lol
das design errinnert mich irgendwie an die göttin der grafikkarten :D
fehlt nur noch eine gewichtsangabe ;)

Merlin31

2003-06-16, 23:53:32

mehr an die 12 V Schiene angeschlossen.

Ich tippe mal auf Starkstrom ?!?! *g

nagus

2003-06-19, 14:14:01

new news... http://www.warp2search.net/article.php?sid=12749

Anton Shilov from X-bit Labs is reporting that the highly anticipated next gen chip from ATI is said to double performance compared to the company's current flagship Radeon 9800 Pro a.k.a R350. His report goes on that R420 still uses the same technology, which I think is rather unlikely. I doubt that the R3xx technology has this much headroom to be carried over as the base for R4xx hardware to double performance so be wary about Mr. Shilov's assumption.

As we revealed earlier, it will incorporate 110 to 150 million of transistors and will support Pixel and Vertex Shaders 3.0. I expect the part to feature 8 rendering pipelines with 2 texture modules per each or 16 pipelines with 1 texture module per pipe. Its architecture will have much in common with the original R300 and R350/R360.

Talking about manufacturing technology used for the R420, our sources said that the graphics processor will be made using mature TSMC’s 0.15 micron fabrication process which seems to be enough for modern VPUs.

... 2x schneller als 9800PRO und 0,15µm ?! interessant.

Demirug

2003-06-19, 14:22:48

16 Pipelines machen bei einem 256 Bit DDR Interface keinen Sinn wenn man den Speicher nicht extreem hoch Takten kann. Denn bei gleichem Takt von Core und Speicher würde die gesamte BruttoBandbreite nur für das Schreiben des Framebuffers draufgehen.

Bleibt also noch 8*2. Die Frage ist nur was man alles verdoppelt? Um werbetechnisch die doppelte Leistung zu bekommen reicht es ja wenn man von bi(4Texel) auf tri(8Texel) TMUs umsteigt.

Exxtreme

2003-06-19, 15:25:41

Original geschrieben von Demirug
16 Pipelines machen bei einem 256 Bit DDR Interface keinen Sinn wenn man den Speicher nicht extreem hoch Takten kann. Denn bei gleichem Takt von Core und Speicher würde die gesamte BruttoBandbreite nur für das Schreiben des Framebuffers draufgehen.

Da hast du recht, aber GDDR3 ist auf dem Vormarsch. :)

Wenn man den Speicher doppelt so hoch takten kann wie den Chip dann würden 16 Pipes wiederum Sinn machen. Und es würde endlich genug Füllrate für SSAA übrig bleiben. :)

Ailuros

2003-06-19, 19:42:32

Wenn man den Speicher doppelt so hoch takten kann wie den Chip dann würden 16 Pipes wiederum Sinn machen. Und es würde endlich genug Füllrate für SSAA übrig bleiben.

Das heisst wohl wenn die Kerle es endlich schaffen MS und SS voll operativ und problemlos gleichzeitig auf einer Karte zu implementieren.

16 pipes auf 15um? *hust*

Was Shader betrifft, habe ich das irgendwie das Gefuehl dass durch ein paar "workarounds" der Instruction Count umso einiges erhoeht wird. Frage ist dann wohl ob die notwendige arithmetische Effizienz auch wirklich da sein wird.

Wie dem auch sei, zeigen Indizien an mehreren Stellen dass deren naechstes Produkt "sehr nahe" an R3xx sein wird eigentlich Sinn und dabei sieht meine Kristallkugel nur ausschliesslich sparsely sampled MSAA, wo hoechstwahrscheinlich die Anzahl der samples auf 8 erhoeht wird.

***edit: da Texelfuellraten bei 8*2 und 16*1 gleich gross sind, was macht mehr Sinn von einer Preis/Leistungsperspektive? Das Ding darf ja auch nicht mehr als maximal 400$ kosten und mit weniger als 256MB - was auch immer - DDR Speicher, geht es auch nicht mehr.

Demirug

2003-06-19, 20:05:45

[SIZE=1]Original geschrieben von Ailuros
Was Shader betrifft, habe ich das irgendwie das Gefuehl dass durch ein paar "workarounds" der Instruction Count umso einiges erhoeht wird. Frage ist dann wohl ob die notwendige arithmetische Effizienz auch wirklich da sein wird.

F-Buffer und das Instruction Count Problem ist vom Tisch. Problematischer sehe ich da schon die Loops und Conditions. Aber auch hier könnte der F-Buffer helfen.

An jeder stelle die eine Condition enthält baut man einen F-Buffer write ein. Der F-Buffer wird nun von zwei Seiten gefüllt. Die welche die Bedigung erfüllen werden von vorne nach hinten eingespeichert. Die anderen von hinten nach vorne. Sobald der Buffer voll ist merkt man sich die Trennposition. Nun wird der Shader welcher den erfüllt zweig repräsentiert geladen und für alle Fragmente bis zu Trennposition ausgeführt. Dann das gleiche mit dem anderen Shaderteil für die restlichen Fragmente. Danach kann man dann mit dem Code welcher nach der Condition kommt weiter machen.

Loops sind etwas komplizierter aber auch machbar.

Wie performant das ganze nun aber sein würde kann ich nicht sagen. Laut ATI sollen die F-Buffer Read/Writes ja nicht in gewicht fallen weil das was man an Bandbreite dafür braucht entweder im Rest untergeht oder sowieso übrig ist wenn der Shader eher Rechenlastig ist. Das ganze ist zwar nicht unbedingt schön aber mit der vorhandenen Technik noch relative leicht zu realisieren.

Ich sollte mir die ganzen sachen patentieren lassen und wenn dann wirklich mal jemand sowas baut abkasieren. :D

aths

2003-06-19, 22:58:18

Original geschrieben von Exxtreme
Da hast du recht, aber GDDR3 ist auf dem Vormarsch. :)

Wenn man den Speicher doppelt so hoch takten kann wie den Chip dann würden 16 Pipes wiederum Sinn machen. Und es würde endlich genug Füllrate für SSAA übrig bleiben. :) Was, wie gesagt, dann doch keine so tolle Lösung ist, da SSAA erst ab 4x sinnvoll wird, und dann wäre man füllratenmäßig beim 4x1-Design.

Ailuros

2003-06-20, 03:03:10

Original geschrieben von Demirug
F-Buffer und das Instruction Count Problem ist vom Tisch. Problematischer sehe ich da schon die Loops und Conditions. Aber auch hier könnte der F-Buffer helfen.

An jeder stelle die eine Condition enthält baut man einen F-Buffer write ein. Der F-Buffer wird nun von zwei Seiten gefüllt. Die welche die Bedigung erfüllen werden von vorne nach hinten eingespeichert. Die anderen von hinten nach vorne. Sobald der Buffer voll ist merkt man sich die Trennposition. Nun wird der Shader welcher den erfüllt zweig repräsentiert geladen und für alle Fragmente bis zu Trennposition ausgeführt. Dann das gleiche mit dem anderen Shaderteil für die restlichen Fragmente. Danach kann man dann mit dem Code welcher nach der Condition kommt weiter machen.

Loops sind etwas komplizierter aber auch machbar.

Wie performant das ganze nun aber sein würde kann ich nicht sagen. Laut ATI sollen die F-Buffer Read/Writes ja nicht in gewicht fallen weil das was man an Bandbreite dafür braucht entweder im Rest untergeht oder sowieso übrig ist wenn der Shader eher Rechenlastig ist. Das ganze ist zwar nicht unbedingt schön aber mit der vorhandenen Technik noch relative leicht zu realisieren.

Ich sollte mir die ganzen sachen patentieren lassen und wenn dann wirklich mal jemand sowas baut abkasieren. :D

Aechz ein Entwickler kommt immer dahinter was man am Ende meint hehehe.

Soweit ich weiss wurde an der F-buffer Technologie noch ein bisschen herumgefuchtelt, frag mich aber bitte nicht was oder wie. Ich bezweifle trotzdem die Effizienz der ganzen Sache zu einer von Anfang an ausgelegten PS/VS3.0 Architektur, falls derartige Spekulationen auch stimmen sollten.

Hier kommt jedoch die kritische Frage fuer den Entwickler: wenn das obrige nun mal stimmen sollte, was bedeutet es fuer den Entwickler (da ich als Verbraucher sowieso nichts mit dem Zeug anfangen kann)? Oder um es einfacher zu machen, welche Loesung wuerde theoretisch attraktiver fuer den Entwickler sein, der auch vorhat fuer derartige Shader-Komplexitaet fuer die weitere Zukunft zu entwickeln?

Fast haette ich es noch vergessen: macht PS/VS3.0 ohne FP32 pipelines eigentlich Sinn (falls das auch der Fall sein sollte)?

Demirug

2003-06-20, 07:18:11

Original geschrieben von Ailuros
Aechz ein Entwickler kommt immer dahinter was man am Ende meint hehehe.

Soweit ich weiss wurde an der F-buffer Technologie noch ein bisschen herumgefuchtelt, frag mich aber bitte nicht was oder wie. Ich bezweifle trotzdem die Effizienz der ganzen Sache zu einer von Anfang an ausgelegten PS/VS3.0 Architektur, falls derartige Spekulationen auch stimmen sollten.

Hier kommt jedoch die kritische Frage fuer den Entwickler: wenn das obrige nun mal stimmen sollte, was bedeutet es fuer den Entwickler (da ich als Verbraucher sowieso nichts mit dem Zeug anfangen kann)? Oder um es einfacher zu machen, welche Loesung wuerde theoretisch attraktiver fuer den Entwickler sein, der auch vorhat fuer derartige Shader-Komplexitaet fuer die weitere Zukunft zu entwickeln?

Fast haette ich es noch vergessen: macht PS/VS3.0 ohne FP32 pipelines eigentlich Sinn (falls das auch der Fall sein sollte)?

Eine von Anfang an auf PS und VS 3.0 ausgelegte Architektur (CPU ähnlich eben) ist natürlich besser. Es hängt also davon ab was von den Aussagen ATIs bezüglich der Performance verluste beim F-Buffer zu halten ist. ATI sagt das sich die zusätzliche Latenz und der Bandbreitenbedarf beim Lesen und schreiben des F-Buffers nicht negative auswirken wird. Bei Aussagen das es etwas "umsonst" gibt bin ich aber immer skeptisch. Letzende Endes ist man als Entwickler aber sowieso in der Zwickmühle. Technologische Sonderwege (PS 1.4/2.X) kann man ja zur not noch ignorieren aber gerade bei den Basislevel (X.0 bzw X.1) kommt man leider nicht umhin aufzupassen das sie bei Benutzung bei allen IHVs einigermassen laufen.

Bei einem R420 mit dieser Technik sehe ich das aber nicht als so kritisch. Der Chip ist Highend und hat deswegen einen schnellen Zyklus. Bis man die 3.0 Shader richtig nutzt haben die meisten die sich einen R420 gekauft haben schon wieder was neues. Technologie im Midrange und vorallem im Lowend Segment ist das kritischer weil langlebiger.

Bei den VS setzt man ja schon lange auf FP32. Bei den Vertexshadern ist FP32 nicht so wichtig solange man nicht vorhat das was hinten herauskommt vorne wieder in einen Vertexshader einzuspeisen. Das meiste der PS 3.0 Funktionalität würde sogar Sinn machen wenn man nur Integer ALUs hätte.

Ailuros

2003-06-20, 09:43:28

Das meiste der PS 3.0 Funktionalität würde sogar Sinn machen wenn man nur Integer ALUs hätte.

Hmmm...keine Ahnung ob es relevant ist, aber waere es mit 3.0 Shadern so langsam Zeit die PS/VS zu vereinigen?

Falls das der Fall waere (wenn es noch nicht zu frueh dafuer ist) und NV40 auch tatsaechlich eine solche Vereinigung haben wird, muesste dann theoretisch ATI nicht auch einem aehnlichen Weg folgen?

In so einem Fall erscheint mir die F-buffer Loesung eigentlich gar nicht so schlecht, aber das wuerde R4xx wiederum zuweit von R3xx abhaken IMHO.

Noch wichtiger: ist dx9.0 fuer so eine Vereinigung theoretisch "reif" genug, oder sollte man aehnliches nicht vor Ende 2004 (oder sogar spaeter) erwarten?

Demirug

2003-06-20, 10:10:03

Original geschrieben von Ailuros
Hmmm...keine Ahnung ob es relevant ist, aber waere es mit 3.0 Shadern so langsam Zeit die PS/VS zu vereinigen?

Falls das der Fall waere (wenn es noch nicht zu frueh dafuer ist) und NV40 auch tatsaechlich eine solche Vereinigung haben wird, muesste dann theoretisch ATI nicht auch einem aehnlichen Weg folgen?

In so einem Fall erscheint mir die F-buffer Loesung eigentlich gar nicht so schlecht, aber das wuerde R4xx wiederum zuweit von R3xx abhaken IMHO.

Noch wichtiger: ist dx9.0 fuer so eine Vereinigung theoretisch "reif" genug, oder sollte man aehnliches nicht vor Ende 2004 (oder sogar spaeter) erwarten?

Du rettest mir heute irgendwie den Tag. Gestern Feiertag heute eigentlich keine Lust zum arbeiten aber wenn ich hier was tippe habe ich wenigstens eine Ausrede für mein schlechtes Gewissen. :D

Wenn du mit "Vereinigen" meinst das man Hardwaretechnisch identische Einheiten benutzten sollte so haben IMHO die 3.0 Shader so viele Gemeinsamkeiten das sich das lohnen würde. Aleine um den Designaufwand für zwei Einheiten zu sparen.

Was den NV40 angeht bin ich mir aber nicht wirklich sicher ob man das dort schon macht. Meine Unsicherheit kommt aber zum grössten Teil daher das ich immer noch keine Details zu dem Vertexshader Array habe.

Ailuros

2003-06-20, 19:16:46

Wenn du mit "Vereinigen" meinst das man Hardwaretechnisch identische Einheiten benutzten sollte so haben IMHO die 3.0 Shader so viele Gemeinsamkeiten das sich das lohnen würde. Aleine um den Designaufwand für zwei Einheiten zu sparen.

Irgendwie ist mir R4xx immer noch ein Raetsel, weil viel zu viel Schmarren spekuliert wird und keiner sich dabei auf die wichtigen Fragen konzentriert.

Ich wuerde gerne wissen in wiefern der R4xx auf der R3xx Architektur basieren wird. Bei R3xx gibt es 4 VS Einheiten. Wenn man sehr wenig dabei veraendern wuerde dann muesste man theoretisch eigentlich den Core hoellisch hoch takten um VS Leistung auch zu erhoehen.

Die VS Einheiten zu verdoppeln klingt auch nicht gerade als eine so tolle Loesung. Ein array waere dann wohl auch fuer R4xx die beste Loesung.

Meine Frage basiert eher darauf, dass wenn man sich schon mit arrays beschaeftigt in Hartware, warum dann nicht gleich eine ultra-starke multi-array Konfiguration die dann PS und VS zur gleichen Zeit aufnehmen kann. Es muesste nicht allzu schwer sein zu realisieren, wobei dann eventuell PS und VS auch parallel gerendert werden koennen.

Von Deiner vorigen Antwort schaetze ich dass DX9.0 als API fuer so eine Loesung kein Problem sein koennte (API Kompatibilitaet).

Wenn das ganze dann eigentlich fuer NV50/R500 geplant ist, dann ist der einzige Grund den ich im Kopf habe, dann eher festgedrahtete T&L Leistung. Bei zu hoher Programmierbarkeit, koennte diese schnell problematischer werden als vorgesehen oder nicht? Auf jeden Fall ist dx7 T&L Leistung wohl heutzutage immer noch aeusserst wichtig.

Demirug

2003-06-20, 19:26:54

Original geschrieben von Ailuros
Meine Frage basiert eher darauf, dass wenn man sich schon mit arrays beschaeftigt in Hartware, warum dann nicht gleich eine ultra-starke multi-array Konfiguration die dann PS und VS zur gleichen Zeit aufnehmen kann. Es muesste nicht allzu schwer sein zu realisieren, wobei dann eventuell PS und VS auch parallel gerendert werden koennen.

Die Idee hatte ich auch schon. Vorallem aus Lastverteilungsgründen sollte das Vorteile bringen.

Von Deiner vorigen Antwort schaetze ich dass DX9.0 als API fuer so eine Loesung kein Problem sein koennte (API Kompatibilitaet).

Ja das wäre keine Problem.

Wenn das ganze dann eigentlich fuer NV50/R500 geplant ist, dann ist der einzige Grund den ich im Kopf habe, dann eher festgedrahtete T&L Leistung. Bei zu hoher Programmierbarkeit, koennte diese schnell problematischer werden als vorgesehen oder nicht? Auf jeden Fall ist dx7 T&L Leistung wohl heutzutage immer noch aeusserst wichtig.

Ach HT&L ist eigentlich so primitive das man das leicht mit einem Vertexshader emulieren kann und ein Vertexarray kann ja Vertexshader ausführen. Sowohl nvidia wie auch der ATI haben ja keine echte HT&L Einheit mehr.

The Jackal

2003-06-24, 00:58:05

Ich frage mich nur eines.

Wie will man die 8x2 wenn es real wird den überhaupt kühlen?

Bedenkt man das schon der R350 ca. 110 mio Transistoren hat.

Dann müßte die 8x2 Architektur locker 180 mio Transistoren verschlucken können.

Bliebe es dann bei 0,15µ Prozess muß man schon Diamantspliter in das Die einarbeiten um die HotSpots überhaupt noch kühlen zu können.

Selbst bei 0,13 wird das noch ein ritt auf der Rasierklinge, den man muß mehr MHz bringen als in der letzt vorgestellten Karte, und mann hat mit mit den unmengen an Transis zu kömpfen.

Ailuros

2003-06-24, 02:36:30

Bei der R300 dachte ich auch dass 107M Transistoren/8*1/>300MHz auf 15nm so gut wie unmoeglich ist. Ob es immer noch Platz fuer mehr Transistoren und zur gleichen Zeit hoehere Taktraten ie >450-500MHz auf 15nm moeglich sind, klingt immer noch unwahrscheinlicher.

Bei 13nm werden wohl alle IHV´s mehr oder weniger auf aehnliche Probleme treffen, bei gleichwertiger Chipkomplexitaet, wobei jedoch zugegeben NVIDIA schon die groesste Erfahrung damit hat. Inwiefern dann Fabs wie TSMC diese Erfahrung auch weiterleiten koennen, hab ich keine Ahnung.

Wenn die Geruechte fuer R4xx/NV4x fuer DDR3 stimmen sollten, spielt wohl die Verfuegbarkeit derartigen Speicher auch noch eine Rolle. Das Ziel laut Uttar/nVnews von NVIDIA soll ja 550-600/700-800MHz sein, was wohl gigantische Fuellraten/Bandbreiten andeutet (das heist nicht das ich auch gleich alles glaube; die Karte muss sich auch auf logischem Preisniveau halten).

Auf jeden Fall sieht es als ob Anfang 2004 hoechstinteressant sein wird (sic; das wird wohl vor jeder neuen Generation gesagt :D ).

seahawk

2003-06-24, 08:01:43

Ja NV und R329 werden spannend. Bin gespannt was die Chips bringen werden.

Bis dahin muss meine R300 durchhalten. Ersetzt wird sie dann durch ne R420/NV40.

Aquaschaf

2003-06-24, 21:36:00

Original geschrieben von The Jackal
Ich frage mich nur eines.

Wie will man die 8x2 wenn es real wird den überhaupt kühlen?

Bedenkt man das schon der R350 ca. 110 mio Transistoren hat.

Dann müßte die 8x2 Architektur locker 180 mio Transistoren verschlucken können.

Bliebe es dann bei 0,15µ Prozess muß man schon Diamantspliter in das Die einarbeiten um die HotSpots überhaupt noch kühlen zu können.

Selbst bei 0,13 wird das noch ein ritt auf der Rasierklinge, den man muß mehr MHz bringen als in der letzt vorgestellten Karte, und mann hat mit mit den unmengen an Transis zu kömpfen.

ich hab zwar keine ahnung, aber afais verschlucken zusätzliche TMU´s nicht so riesige mengen an transistoren, der Großteil der 107Mio. Transistoren ist doch in dern VS/PS verbraten.

Ailuros

2003-06-25, 01:57:06

Original geschrieben von Aquaschaf
ich hab zwar keine ahnung, aber afais verschlucken zusätzliche TMU´s nicht so riesige mengen an transistoren, der Großteil der 107Mio. Transistoren ist doch in dern VS/PS verbraten.

Schon.

Obwohl ein 8*2 setup zwar Vorteile geben kann, bin ich mir nicht so sicher dass die Vorteile auch um jeden Preis ueberwiegen werden. Theoretisch ist erstmal ein 8*1 setup genug mit einem 256-bit breitem Bus; wieso soll dann genauso theoretisch ein 256bit bus genug sein fuer 8*2?

Demirug

2003-06-25, 07:27:08

Original geschrieben von Ailuros
Schon.

Obwohl ein 8*2 setup zwar Vorteile geben kann, bin ich mir nicht so sicher dass die Vorteile auch um jeden Preis ueberwiegen werden. Theoretisch ist erstmal ein 8*1 setup genug mit einem 256-bit breitem Bus; wieso soll dann genauso theoretisch ein 256bit bus genug sein fuer 8*2?

Weil die Anzahl der Pixel/Takt hier das wichtiger Kriterium ist. Es bringt einfach nicht so viele Pixel zu erzeugen nur und sie dann nicht in den Framebuffer schreiben zu können.

Bei 8 Pixel kommt man auf 8*32 = 256 Bit. Bei gleichem Takt (Core/Memory)ist da schon die Hälfte der Brutto Kapazität der Bandbreite weg. Ergo für 16 Pixel/Takt braucht man entweder einen 512 Bit Bus oder einen 256 Bit Bus mit doppler Taktrate wie der Core bzw Quad übertragung.

Für 8*2 trift das nun aber nicht ganz zu. Es können weiterhin nur 8 Pixel/Takt erzeugt werden aber das mögliche Arbeitsvolumen pro Pixel steigt. Zusätzliche Bandbreite wird zwar auch in diesem Fall gebraucht aber TMUs sind ja über Caches entkoppelt. Bei einem 256 Bit Bus ist ein 8*2 Setup derzeit einer der wenigen Wege die Leistung zu steigern.

Ailuros

2003-06-25, 08:29:56

Was aber auch nicht ohne Nachteile kommt. Bei einem kompletten random texture read wie z.B. beim PS2.0 Test in 3dmark2003 wird bei einem 256bittigen bus eine Unmenge von unnoetiger Data gelesen, so wie ich das verstanden habe.

Demirug

2003-06-25, 09:09:49

Original geschrieben von Ailuros
Was aber auch nicht ohne Nachteile kommt. Bei einem kompletten random texture read wie z.B. beim PS2.0 Test in 3dmark2003 wird bei einem 256bittigen bus eine Unmenge von unnoetiger Data gelesen, so wie ich das verstanden habe.

Ja bei Radom reads nimmt natürlich die Effektivität des Caches ab. Die Menge an unnötig gelesen Daten hängt dabei aber nicht von der Breite des Busses sonder von der Breite eines Speicherkanals und dem Textureformat ab.

Ailuros

2003-06-25, 10:27:25

Original geschrieben von Demirug
Ja bei Radom reads nimmt natürlich die Effektivität des Caches ab. Die Menge an unnötig gelesen Daten hängt dabei aber nicht von der Breite des Busses sonder von der Breite eines Speicherkanals und dem Textureformat ab.

Ich hab micht jetzt nur mal auf die "read efficiency" konzentriert, wobei es so wie ich es sehe schlimmer wird mit 8*2 vs 8*1.

Was passiert eigentlich wenn random texture reads in der vorsehbaren Zukunft dann staendig zunehmen?

Ich moechte jetzt nicht alles ploetzlich schwarz malen aber ich hab das Gefuehl dass IHV's sehr viel in Forschung von Markt-Trends investieren, und dass solche "unscheinbare" Kleinigkeiten nicht uebersehen werden.

Natuerlich ist immer die Endentscheidung dann fuer die best-balancierte Loesung aus so viel wie moeglichen Aspekten. Ohne Aenderungen sieht das ganze nicht so leicht aus IMO.

Demirug

2003-06-25, 11:11:56

Original geschrieben von Ailuros
Ich hab micht jetzt nur mal auf die "read efficiency" konzentriert, wobei es so wie ich es sehe schlimmer wird mit 8*2 vs 8*1.

Natürlich, je mehr TMUs random reads mit der gleichen Bandbreite ausführen müssen desto grösser die Gefahr des Leerlaufs. Auf der anderen Seite steigt natürlich auch die ALU Leistung (wenn man richtige x*y Pipes baut) und diese ist ja unabhängig von der Bandbreite. Der Gewinn durch 8*2 im verhältniss zu 8*1 wird also stark vom jeweiliegen Shader abhängen.

Was passiert eigentlich wenn random texture reads in der vorsehbaren Zukunft dann staendig zunehmen?

eigentlich gefällt mir das "random reads" als Begriff nicht so sehr. Denn "Random" sind sie ja eigentlich alle. Ich denke aber wir meinen beide die Streuung aufeineraderfolgender Reads innerhalb der gleichen Texture. Ein Mittel dagegen wäre die Reads zu verzögern und etwas zu sortieren. Das könnte durchaus etwas bringen weil man dependent Reads ja primär für Effekte die irgendwas mit Spiegel oder lichtbrechung im Allgemeinen zu tun haben und da ist die Streung ja nicht ganz so extreme. Das schlimmste was man einen Texturecache aber antun kann ist Rauschen über eine folge von dependent reads zu erzeugen. Das wird aber wohl einer der kommenden PS 2.0 Effekte werden. Ich hoffe da mittelfirstig auf eine Lösung die Rauschen (noise) direkt im Chip realieseren kann.

Ich moechte jetzt nicht alles ploetzlich schwarz malen aber ich hab das Gefuehl dass IHV's sehr viel in Forschung von Markt-Trends investieren, und dass solche "unscheinbare" Kleinigkeiten nicht uebersehen werden.

Ja wobei "Markttrend" in diesem Fall heist die Spieleentwickler zu fragen welche Effekte sie in Zukunft planen und da ja nur wenige grosse da die Marchrichtung angeben ist das recht einfach. Aus einer solchen Marktforschung ist ja auch sicherlich die Erkenntniss gekommen das man die Stencilbuffer Performance steigern muss.

Natuerlich ist immer die Endentscheidung dann fuer die best-balancierte Loesung aus so viel wie moeglichen Aspekten. Ohne Aenderungen sieht das ganze nicht so leicht aus IMO.

Ja die richtige Mischung macht es eben. Es bringt nun mal nichts ein Fillratemonster zu bauen wenn dann keine Transitoren mehr übrig bleiben um eine entsprechenden Vertexleistung zu haben. Und je mehr Funktionen der 3d Pipeline vom Chip übernommen werden desto schwieriger wird es die Balance zu finden.

robbitop

2003-06-25, 11:32:41

naja 8x2 wäre nur wirklich sinnvoll wenn jede TMU eine ALU bekäme. Dann wären wir wirklich bei 180 Mio Transistoren, ohne andere Änderungen.
Wenn man jedoch trilineare TMUs nutzen würde, wäre das nicht nötig. Soviel mehr kosten die nicht, und da inzwische eh jeder trilinear filtert, düfte das die Füllrate verdoppeln. Dadurch sind allerdings die AF Modi Performance bei beiden IHVs nutzlos, da die bilineare Füllrate nicht steigt.

Demirug

2003-06-25, 11:43:02

Original geschrieben von robbitop
naja 8x2 wäre nur wirklich sinnvoll wenn jede TMU eine ALU bekäme. Dann wären wir wirklich bei 180 Mio Transistoren, ohne andere Änderungen.
Wenn man jedoch trilineare TMUs nutzen würde, wäre das nicht nötig. Soviel mehr kosten die nicht, und da inzwische eh jeder trilinear filtert, düfte das die Füllrate verdoppeln. Dadurch sind allerdings die AF Modi Performance bei beiden IHVs nutzlos, da die bilineare Füllrate nicht steigt.

Ein bischen mehr kann 8*2(bi) gegenüber 8*1(tri) schon bringen aber auch nur wenn man eben bi benutzt.

Die AF Performance modies müssen dadurch nicht zwangsläufig nutzloss sein. Man sollte mit minimalen Mehraufwand auch eine TMU bauen können die wahlweise tri oder 2xAF beherscht.

robbitop

2003-06-25, 11:46:48

ginge auch mehr? sprich tri2xAF? (oder bin ich jetzt zu gierig :D ?)

Ailuros

2003-06-25, 11:48:15

Ja wobei "Markttrend" in diesem Fall heist die Spieleentwickler zu fragen welche Effekte sie in Zukunft planen und da ja nur wenige grosse da die Marchrichtung angeben ist das recht einfach. Aus einer solchen Marktforschung ist ja auch sicherlich die Erkenntniss gekommen das man die Stencilbuffer Performance steigern muss.

Ich dachte ich spreche mit einem Entwickler hier... ;)

Also was stencil ops betrifft, fuchtelt ja Carmack jetzt schon unendlich an dem Doom3 Projekt rum. Allein zu bedenken wie oft er seine Engine lizensieren koennte reicht.

eigentlich gefällt mir das "random reads" als Begriff nicht so sehr. Denn "Random" sind sie ja eigentlich alle. Ich denke aber wir meinen beide die Streuung aufeineraderfolgender Reads innerhalb der gleichen Texture. Ein Mittel dagegen wäre die Reads zu verzögern und etwas zu sortieren. Das könnte durchaus etwas bringen weil man dependent Reads ja primär für Effekte die irgendwas mit Spiegel oder lichtbrechung im Allgemeinen zu tun haben und da ist die Streung ja nicht ganz so extreme. Das schlimmste was man einen Texturecache aber antun kann ist Rauschen über eine folge von dependent reads zu erzeugen. Das wird aber wohl einer der kommenden PS 2.0 Effekte werden. Ich hoffe da mittelfirstig auf eine Lösung die Rauschen (noise) direkt im Chip realieseren kann.

Tja leider haben wir heute nur 8*1 setups mit entweder 128bit breitem bus oder 256bits; aber keinen 8*2 chip.

Die einzigen Tests die ich finden konnte sind die hier, wobei es sich aber um eine 9700PRO handelt und nicht um eine 9700.

http://www.hardocp.com/article.html?art=NDY2LDc=

http://www.hardocp.com/article.html?art=NDQ4LDY=

Ich hab jetzt zwar keine Ahnung woher die Limitationen kommen, aber die Unterschiede zwischen 9500PRO und 9700 muessten in diesen Tests gering sein. Wuerden vielleicht dieselben Tests in hoeheren Aufloesungen den Unterschied machen?

(NOTIZ: ich will jetzt auf keinen Fall die Wichtigkeit von 256bittigen bussen und ueberhaupt hoeheren Bandbreiten bestreiten, ganz im Gegenteil. Ich frag mich nur seit einiger Zeit warum >9700 der Abstand zu den mainstream Modellen so klein ist bei solchen Tests, wenn von Grund auf die >9700 zweimal so viel Bandbreite haben).

robbitop

2003-06-25, 11:50:34

genau die Frage habe ich mir auch gestellt...aber ich denke es ist einfach zuwenig Füllrate da

Ailuros

2003-06-25, 12:06:36

Original geschrieben von robbitop
genau die Frage habe ich mir auch gestellt...aber ich denke es ist einfach zuwenig Füllrate da

Wieso setzt dann die 9800PRO nicht gewaltig von der 9700PRO ab im PS2.0 Test? (ich konzentrier mich auf den Test weil er ja den oben erwaehnten "noise" weitgehend enthaelt).

oooops ****edit: ich lass es so stehen um meine Fahrlaessigkeit zu illustrieren. Beide Karten laufen auf gleichem Takt aeeeechzzz...

**editNr2:

skaliert normal nach Taktrate:

http://www.hardocp.com/article.html?art=NDU2LDc=

Demirug

2003-06-25, 12:24:47

Original geschrieben von robbitop
ginge auch mehr? sprich tri2xAF? (oder bin ich jetzt zu gierig :D ?)

Ja klar. Man kann auch eine TMU bauen die direkt jeden Takt ein 16xtriAF sample rauswirft. Aber irgendwann ist das Kosten/Nutzen verhältniss nicht mehr gegeben.

Demirug

2003-06-25, 12:36:14

Original geschrieben von Ailuros
Ich dachte ich spreche mit einem Entwickler hier... ;)

Also was stencil ops betrifft, fuchtelt ja Carmack jetzt schon unendlich an dem Doom3 Projekt rum. Allein zu bedenken wie oft er seine Engine lizensieren koennte reicht.

Und andere werden das mit den Stencilschatten auch nachmachen.

Tja leider haben wir heute nur 8*1 setups mit entweder 128bit breitem bus oder 256bits; aber keinen 8*2 chip.

Die einzigen Tests die ich finden konnte sind die hier, wobei es sich aber um eine 9700PRO handelt und nicht um eine 9700.

http://www.hardocp.com/article.html?art=NDY2LDc=

http://www.hardocp.com/article.html?art=NDQ4LDY=

Ich hab jetzt zwar keine Ahnung woher die Limitationen kommen, aber die Unterschiede zwischen 9500PRO und 9700 muessten in diesen Tests gering sein. Wuerden vielleicht dieselben Tests in hoeheren Aufloesungen den Unterschied machen?

(NOTIZ: ich will jetzt auf keinen Fall die Wichtigkeit von 256bittigen bussen und ueberhaupt hoeheren Bandbreiten bestreiten, ganz im Gegenteil. Ich frag mich nur seit einiger Zeit warum >9700 der Abstand zu den mainstream Modellen so klein ist bei solchen Tests, wenn von Grund auf die >9700 zweimal so viel Bandbreite haben).

Auf welchen von den vielen Tests beziehts du dich genau?

Für mich sieht das alles mehr oder minder im Rahmen aus. Je wichtiger die Bandbreite wird desto mehr kann die 9700 (pro) davon ziehen.

robbitop

2003-06-25, 14:02:59

naja 2xTriAF wäre schon nett :D

Ailuros

2003-06-25, 14:27:57

Und andere werden das mit den Stencilschatten auch nachmachen.

Ich schmeiss jetzt noch wieder ein OT in die Debatte, aber ich frag mich oft ob es nicht billigere und effektivere Schatten-Loesungen gab/gibt als Stencil-Schatten.

Auf welchen von den vielen Tests beziehts du dich genau?

Für mich sieht das alles mehr oder minder im Rahmen aus. Je wichtiger die Bandbreite wird desto mehr kann die 9700 (pro) davon ziehen.

PS2.0 (siehe "noise"). Ich sehe da keine gigantischen Unterschiede die nicht nur zur hoeheren Taktrate eher nachzuleiten sind.

9500PRO@277/270 = 34.5
9500PRO@291/301 = 37.7
9700PRO@325/310 = 40.7

Ich konnte zwar keine 9700@275/270 Resultate finden, aber ich hab das Gefuehl dass die fast identisch sein sollten mit einer 9500PRO, oder mit sehr geringem Abstand.

Demirug

2003-06-25, 14:38:26

Original geschrieben von Ailuros
Ich schmeiss jetzt noch wieder ein OT in die Debatte, aber ich frag mich oft ob es nicht billigere und effektivere Schatten-Loesungen gab/gibt als Stencil-Schatten.

Shadow Buffers sind billiger zu haben aber leider nicht ganz so perfekt.

PS2.0 (siehe "noise"). Ich sehe da keine gigantischen Unterschiede die nicht nur zur hoeheren Taktrate eher nachzuleiten sind.

9500PRO@277/270 = 34.5
9500PRO@291/301 = 37.7
9700PRO@325/310 = 40.7

Ich konnte zwar keine 9700@275/270 Resultate finden, aber ich hab das Gefuehl dass die fast identisch sein sollten mit einer 9500PRO, oder mit sehr geringem Abstand.

AFAIR ist der Noise-Anteil im PS 2.0 Test gar nicht so hoch. Ich müsste dafür aber nochmal ein Blick auf das PS-Programm werfen das ich gerade nicht zur Hand habe.