Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Nvidia bringt NV40-Technologie in das Mittelklasse-Segment
Leonidas
2004-08-12, 15:35:22
Link zum Artikel:
http://www.3dcenter.org/artikel/2004/08-12_a.php
Quasar
2004-08-12, 15:44:37
"So kommt der NV43-Chip mit [...] 4 Vertexshadern aus,[...]"
B3D sagt laut LS' Zitat was anderes - nämlich 3 VS-Einheiten. Was stimmt?
"lieferbare Slot-Interfaces AGPx8, PCIe x16"
AFAIK sind die AGP8X-Geschichten noch nicht wirklich angekündigt - es hieß nur, "wir können sie machen".
" Das muss von von zwei Seiten sehen:"
Das muss man von zwei....
"Wir erwarten von der GeForce 6600GT genug Leistung, um in praktisch allen Spielen 4x Antialiasing sinnvoll einsetzen zu können,"
Da muss ich mal widersprechen. 16GB/s sind ziemlich genau das, was die FX5800u auch bot und mit 4xAA knickte diese teils doch ziemlich ein.
"In einer Nvidia-Präsentation, die wir bewusst nicht zeigen, wird die GeForce 6600GT mit der Radeon X600 verglichen (und das ausgerechnet in Doom 3). Darin sehen wir jedoch keinen Sinn. Die einzige Argumentation hierfür wäre vielleicht, dass PCI Express Mittelklasse-Hardware verglichen würde."
Der Sinn läge in vermutlich vergleichbaren Preisrahmen. Momentan befindet sich die X600(XT) in genau dem Bereich, der von der GF6600 angepeilt wird. Natürlich gäbe es die Möglichkeit, daß ATi die Preise für die X600-Reihe deutlich senkt...
Ansonsten sehr gelungene Zusammenfassung/Interpretation des mageren Materials von nV. =)
"So kommt der NV43-Chip mit [...] 4 Vertexshadern aus,[...]"
B3D sagt laut LS' Zitat was anderes - nämlich 3 VS-Einheiten. Was stimmt?Prüfe ich gerade.
edit: Sind 3 VS. Sry ;(
AFAIK sind die AGP8X-Geschichten noch nicht wirklich angekündigt - es hieß nur, "wir können sie machen". Ja, ist noch nicht angekündigt, wird aber kommen. Ist allerdings kurzfristig nicht lieferbar. Wird geändert.
"Wir erwarten von der GeForce 6600GT genug Leistung, um in praktisch allen Spielen 4x Antialiasing sinnvoll einsetzen zu können,"
Da muss ich mal widersprechen. 16GB/s sind ziemlich genau das, was die FX5800u auch bot und mit 4xAA knickte diese teils doch ziemlich ein.Die 5800 ist eine HighEnd-Karte und man verlangte zu ihrer Zeit HighEnd-Leistung. Wenn man mit full-tri AF spielt, reichen schon 2 Texturen, dass die ROPs der 6600 das AA nicht mehr limitieren. Insofern lehne ich mich mit der Behauptung aus dem Fenster, dass es für 4x AA reicht (denn für 2x fulltri-AF reichts auf jeden Fall.) Ggü. der 5800 bietet die 6600 verbesserte Farbkomprimierung.
"In einer Nvidia-Präsentation, die wir bewusst nicht zeigen, wird die GeForce 6600GT mit der Radeon X600 verglichen (und das ausgerechnet in Doom 3). Darin sehen wir jedoch keinen Sinn. Die einzige Argumentation hierfür wäre vielleicht, dass PCI Express Mittelklasse-Hardware verglichen würde."
Der Sinn läge in vermutlich vergleichbaren Preisrahmen. Momentan befindet sich die X600(XT) in genau dem Bereich, der von der GF6600 angepeilt wird. Natürlich gäbe es die Möglichkeit, daß ATi die Preise für die X600-Reihe deutlich senkt... In dieser Area gibt es einen Thread in dem es darum geht, zu welchem Zeitpunkt Aussagen gelten und wann sie überholt sind. Imo wird der Preis der X600 sehr bald überholt sein – wenn der für die 6600 anvisierte Preis sich im Markt tatsächlich durchsetzt.
Sephiroth
2004-08-12, 15:59:24
Schöner Artikel aths.
Wird sicher interessant, wenn es dann PCIe Boards in ausreichender Stückzahl gibt und besonders welche mit zwei PCIe x16 Slots für den SLI-Modus der 6600GT :D
Btw.
Unter den Bildern ...
link: GeForce 6600, rechts: GeForce 6600GT
links ;)
Schöner Artikel aths.
Wird sicher interessant, wenn es dann PCIe Boards in ausreichender Stückzahl gibt und besonders welche mit zwei PCIe x16 Slots für den SLI-Modus der 6600GT :DDas Thema SLI hielt ich absichtlich flach. Im Moment sind das ungelegte Eier. Mittelfristig, wenn sich PCIe durchgesetzt hat, und die 6600 noch immer begehrt sein sollte (was ja keinesfalls sicher ist) wäre das natürlich eine tolle Option. Sofern Nvidia den Nachweis erbracht hat, dass SLI mit (praktisch) allen Spielen kompatibel, und der Leistungszuwachs deutlich ist.
Leonidas
2004-08-12, 16:08:04
"So kommt der NV43-Chip mit [...] 4 Vertexshadern aus,[...]"
B3D sagt laut LS' Zitat was anderes - nämlich 3 VS-Einheiten. Was stimmt?
"lieferbare Slot-Interfaces AGPx8, PCIe x16"
AFAIK sind die AGP8X-Geschichten noch nicht wirklich angekündigt - es hieß nur, "wir können sie machen".
VS: Korrekt, es sind nur 3. Gefixt.
Slot-Interfaces: NV wird sich hier raushalten, die Board-Hersteller können liefern, was sie wollen. Und ich denke schon, daß sie die Karten auch auf AGp anbieten werden, wo PCIe momentan noch totale Nische ist.
Quasar
2004-08-12, 16:08:19
Ja, ist noch nicht angekündigt, wird aber kommen. Ist allerdings kurzfristig nicht lieferbar. Wird geändert.
Das ist IMO mit voller Absicht so geschehen - nVidia sagte mal, daß sie nach der eher schlechten Umsetzung von "Verfügbarkeit 45 Tage nach Launch" beim nV40 daran arbeiten wollen und nach PCI-e Grafikkarten gibt's schlicht noch nicht so eine große Nachfrage im Retailmarkt, so daß die vorhandene Nachfrage mit weniger Exemplaren bedient werden kann.
Ich weiß, ich weiß, meine Para.... ;)
Leonidas
2004-08-12, 16:11:10
Das Thema SLI hielt ich absichtlich flach. Im Moment sind das ungelegte Eier. Mittelfristig, wenn sich PCIe durchgesetzt hat, und die 6600 noch immer begehrt sein sollte (was ja keinesfalls sicher ist) wäre das natürlich eine tolle Option. Sofern Nvidia den Nachweis erbracht hat, dass SLI mit (praktisch) allen Spielen kompatibel, und der Leistungszuwachs deutlich ist.
Man muß hier in erster Linie arbwarten, ob entsprechend günstige SLI-Mainboards in den Markt kommen. Was nützen die günstigen SLI-Grafikkarten, wenn das SLI-Mainboard 400 Steine kostet?
Only 4 ROPs :down:Regarding this ROP-stuff, there will be an extra article in some weeks (about both Radeon and GeForce hardware). But before this, I plan to release another NV40-related article series.
@aths:Immerhin muss die halbierte Speicherbandbreite pro Takt nur eine halbierte Pixelarchitektur bedienen.
But the chip has a 500Mhz clock compared to an 6800U 400.This is more than a 1/2 fillrate.But less than 1/2 mem.band.
Are you sure that 6600 xx has only 4 ROPs .
6600gt has 4000Mpixel fillrate and 16Gb mem.band.,the 6800u 6400Mp. and 35.2Gb
Above 1280 res. 6600gt will always be limited by mem.band.
pajofego
2004-08-12, 16:38:50
Super Artikel, mal wieder 1a Infos!
Freue mich schon auf die ersten Benchmarkergebnisse! Persönlich würde mich ein Vergleich der Pixel Shaderleistungsunterschiede zw. der 6600 u. der 6800 interessieren.
Gruss pajofego
@aths:Immerhin muss die halbierte Speicherbandbreite pro Takt nur eine halbierte Pixelarchitektur bedienen.
But the chip has a 500Mhz clock compared to an 6800U 400.This is more than a 1/2 fillrate.But less than 1/2 mem.band.Yes. But it looks like the average 5 bytes per pixelpipeline and clock are OK for 6800 U. 6600 GT offers still 4 bytes per pixelpipeline and clock, this should be ok for a midrange-product.
Are you sure that 6600 xx has only 4 ROPs . This is the information I got.
Super Artikel, mal wieder 1a Infos!
Freue mich schon auf die ersten Benchmarkergebnisse! Persönlich würde mich ein Vergleich der Pixel Shaderleistungsunterschiede zw. der 6600 u. der 6800 interessieren. Takt für Takt erwarte ich, dass die 6600 pro Pixelpipe ein wenig schneller ist als 6800. Bei dem Mehrtakt von 25% und der geringeren Pipelinezahl von 50% käme man auf ca. 63% der 6800 Ultra (bzw. 71% der 6800 GT.) Ich halte es für möglich, dass praktisch 70% (bzw. knapp 80%) der arithmetischen Shaderleistung von der 6800 U (GT) geboten werden. Mit der 6800 könnte die 6600 GT – rein von der arithmetischen Pixelshaderleistung – sogar gleichziehen, bzw. sie minimal übertreffen.
In der Spiele-Praxis erwarte ich allerdings, dass eine 6600 GT keiner 6800 das Wasser reichen kann – mit Ausnahme der LE vielleicht, aber auch nur in bestimmten Situationen.
zeckensack
2004-08-12, 16:57:11
Yes. But it looks like the average 5 bytes per pixelpipeline and This is the information I got.What kind of ROP? I think this may be more complicated than it appears to be. The information could be referring to "dual ROPs" for lack of a better term. I.e. FP16 capable ROPs, that can be split in two for integer render targets, and further for Z/stencil.
Just guessing here ...
What kind of ROP? I think this may be more complicated than it appears to be. The information could be referring to "dual ROPs" for lack of a better term. I.e. FP16 capable ROPs, that can be split in two for integer render targets, and further for Z/stencil.
Just guessing here ...Your quote was from a discussion about the memory bandwidth :)
I dont think an FP16-ROP can be splitted into two integer-ROPs. FP16 has a mantissa of 10 or 11 bits, while the integer-ROP needs 8 Bit. NV43-ROPs still can work either as Z/Stencil + Alphablending or Z/Stencil + Z/Stencil. I think, an NV4x-ROP has two 2 Z/Stencil and 1 Alphablending unit build in, but is limited to 2 units per clock.
@aths:Denkbar wäre eine Verkleinerung der Kanalbreite der NV40 4x Crossbar von 128 auf 64 Bit. Nvidia realisierte aber einfach ein "halbes" NV40-Interface (sprich, statt 4 nur 2 Kanäle á 128 Bit).
I really don't understand what did you mean here.nv40 has no 4x 128 bit mem.con.(512 bit :| ) .It has a 4x 64 bit.
I'm curious,does nv43 has a 2x 64 bit OR a 4x 32 bit mem.con.
pajofego
2004-08-12, 17:50:32
Takt für Takt erwarte ich, dass die 6600 pro Pixelpipe ein wenig schneller ist als 6800. Bei dem Mehrtakt von 25% und der geringeren Pipelinezahl von 50% käme man auf ca. 63% der 6800 Ultra (bzw. 71% der 6800 GT.) Ich halte es für möglich, dass praktisch 70% (bzw. knapp 80%) der arithmetischen Shaderleistung von der 6800 U (GT) geboten werden. Mit der 6800 könnte die 6600 GT – rein von der arithmetischen Pixelshaderleistung – sogar gleichziehen, bzw. sie minimal übertreffen.
In der Spiele-Praxis erwarte ich allerdings, dass eine 6600 GT keiner 6800 das Wasser reichen kann – mit Ausnahme der LE vielleicht, aber auch nur in bestimmten Situationen.
mmh, dass hört sich verdammt gut an! Die 6600 GT steht bei mir ab sofort unter Beobachtung, hatte vorgehabt noch die FX 5900 zu holen, aber bei diesen Leistungsdaten und dem anvisierten Preis, einfach spitze! :biggrin:
zeckensack
2004-08-12, 18:05:05
Your quote was from a discussion about the memory bandwidth :)
I dont think an FP16-ROP can be splitted into two integer-ROPs. FP16 has a mantissa of 10 or 11 bits, while the integer-ROP needs 8 Bit. NV43-ROPs still can work either as Z/Stencil + Alphablending or Z/Stencil + Z/Stencil. I think, an NV4x-ROP has two 2 Z/Stencil and 1 Alphablending unit build in, but is limited to 2 units per clock.Okay, so I'm obviously confused about NV4x ROPs :ugly2:
I always thought that you get "full speed" on 8 bit per channel integer targets, regardless of blending, "double speed" with pure Z/Stencil and "half speed" w FP16, again, regardless of blending. My point of reference here ("full speed") is 16 ROPs on NV40.
It was my impression that "half speed" with FP16 is a chip limitation, but it doesn't hurt in practice because of bandwidth constraints. "Full speed" would just overburden the memory interface, it wouldn't work out. So it's just "not that bad"(TM), but still a concious design decision to limit throughput in that mode.
But I'm still wondering ... did the same source that stated 4 ROPs on NV43 also say that NV40 had 16 ROPs? I think that may be important ...
@aths:Denkbar wäre eine Verkleinerung der Kanalbreite der NV40 4x Crossbar von 128 auf 64 Bit. Nvidia realisierte aber einfach ein "halbes" NV40-Interface (sprich, statt 4 nur 2 Kanäle á 128 Bit).
I really don't understand what did you mean here.nv40 nas no 4x 128 bit mem.con.(512 bit :| ) .It has a 4x 64 bit.
I'm curious,does nv43 has a 2x 64 bit OR a 4x 32 bit mem.con.The article gives the answer :) Its 2x 64 Bit DDR (logical 2x 128 Bit.)
Melron
2004-08-12, 18:52:37
ersmal spitzen Artikel !!!
das mit dem SLI is sicher ne tolle Sache (like Voodoo2 anno 19xx *g*), nur stell ich mir die Frage wie es mit der Belüftung der ersten karte laufen wird, da die zweite ja direkt davor sitzt, bekommt die dann noch genu luft ?
bin mal gespannt wie das in der Praxis an nem heißem Sommertag läuft *gg*
greetz
Melron
Madkiller
2004-08-12, 19:05:02
Letzter Absatz:
Im übrigen ergibt sich der beachtenswerte Umstand, daß die GeForce 6600 nach dem US-Listenpreis nur 25 Prozent günstiger ist als die GeForce 6800GT, aber mit immerhin 40 Prozent weniger Chiptakt antritt.
Soll das nicht "6600GT" heißen? :)
Leonidas
2004-08-12, 19:31:54
I really don't understand what did you mean here.nv40 nas no 4x 128 bit mem.con.(512 bit :| ) .It has a 4x 64 bit.
I'm curious,does nv43 has a 2x 64 bit OR a 4x 32 bit mem.con.
Nein. Chip-intern gibt es kein DDR. Sprich: Intern arbeitet der NV40 als 512 Bit Chip. Demzufolge arbeitet das Speicherinterface logisch gesehen als 4x128 Bit. Nur der Speicher selber arbeitet im DDR-Verfahren, nicht aber der Grafikchip selber.
Ich hoffe, ich irre mich in diesem Punkt nicht :-)
Leonidas
2004-08-12, 19:33:17
Letzter Absatz:
Soll das nicht "6600GT" heißen? :)
Ja, gefixt.
@Leonidas
The nv40 micro arhitecture has an 256 bit width memory controler that is segmented in to four channels of 64 bits.There is no logical width by memory controlers.For example mem. con. of an 6800u works with the speed of the chip =400Mhz
@aths
Than if it is true,that it really is a two times 64 bit,the bandwidth is going to be crippled.
Remember of the Celeron (northwood) L2 cache ?
@aths
Than if it is true,that it really is a two times 64 bit,the bandwidth is going to be crippled.
Remember of the Celeron (northwood) L2 cache .Die Bandbreite bleibt bei logischen 256 Bit pro Takt. Eine 4x-Crossbar wäre besser, die 2x-Crossbar ist aber kein Beinbruch.
Natürlich arbeitet der Speicherzugriff mit dem Speichertakt. Der Chip kann aber asynchron reinschreiben, bis der Cache voll ist. Pro RAM-Takt gehen 256 Bit Daten über den Bus, als 2 Pakete à 128 Bit. Jede Quad-Pipe hat praktisch "sein" RAM-Interface. Vermutlich ist aber ein Lastenausgleich möglich. Selbst wenn das nicht gegeben wäre, dürfte das die Leistung nicht gleich so brutal beeinflussen (geschätzt 10%.)
Okay, so I'm obviously confused about NV4x ROPs :ugly2:
I always thought that you get "full speed" on 8 bit per channel integer targets, regardless of blending, "double speed" with pure Z/Stencil and "half speed" w FP16, again, regardless of blending. My point of reference here ("full speed") is 16 ROPs on NV40.
It was my impression that "half speed" with FP16 is a chip limitation, but it doesn't hurt in practice because of bandwidth constraints. "Full speed" would just overburden the memory interface, it wouldn't work out. So it's just "not that bad"(TM), but still a concious design decision to limit throughput in that mode.
But I'm still wondering ... did the same source that stated 4 ROPs on NV43 also say that NV40 had 16 ROPs? I think that may be important ...Es wären ja Alphablender in den ROPs denkbar, die bei FP16 halt 2 Takte brauchen. Meine Sourcen sind beides mal Nvidia :) Solche Details muss man denen aber aus der Nase ziehen, wenn das überhaupt möglich ist. Bezüglich der 6600 wurden leider nicht alle Fragen beantwortet.
Splittbare ROPs halte ich für schwierig zu designen. Vielleicht sparte man am Ende irgendwo Transistoren, allerdings sind ROPs wohl nicht so teuer – außer bei FP-Logik, natürlich. Diese betrifft aber nur den Alphablender (Z-Vergleich kann ja, FP hin oder her, mit Integer-Logik gemacht werden) wenn ich mich nicht irre.
@aths
I really don't understand what are you tallking about.The mem. con. has an wigth of 128 bit,that means 128 bit can be sent trough him in one clock. No mather in what direction.And of course,i know that the mem.con. in the chip is working with the chip clock but at the same time asynchronous with the mem. clock.
Only memory can work in DDR mode,but this means that the mem. chip on the modul (exampel ddr 3200MB aka 400MHz) is working with 200 MHz but the information can be read and wrote in one clock.
@aths
I really don't understand what are you tallking about.The mem. con. has an wigth of 128 bit,that means 128 bit can be sent trough him in one clock. No mather in what direction.And of course,i know that the mem.con. in the chip is working with the chip clock but at the same time asynchronous with the mem. clock.
As far as i know/understand it, that's wrong, you can send 256bit through a 128bit wide interface with DDR technology in one clock cycle.
BTW, Offtopic, but what country do you come from? just curious :)
@Mike
That is a secret.
On topic
Yes you can transport 256bits through a 128 bit mem.con. but in 2 clocks.
Example:Every northbridge's mem.con. can only transports so much MBs depended on the number of MBs that the memory can give it.DDr 400 aka 3200 gives it 3.2GB of data.Mem.con. can transport it,but it is 64 bits width in single channel mode.
Nerothos
2004-08-13, 00:41:55
@Mike:
I think he comes from a german-speaking country. Why? His German is better than his English *gnihihi*
(Sorry @ IVN ;) )
@aths:
Schöner Artikel. War nett zu lesen. Eigentlich wie immer *g*
Wird es noch lange dauern bis zu dem im Artikel versprochenen... ähhh nächsten Artikel? :D
@Commander Larve
That wasn't nice! :mad:
Schön zu lesen!
Mann merkt es euch an das Ihr sehr viel Scheckung von dem habt, was Ihr euch da verspricht und ich freue mich schon auf weitere Berichte über diese wundersame SLI-Technologie.
Neues Mainboard: ca. 200€
Neue Grakas, 2*6600: ca. 400€
Lol,
Zitat (ATHS): Takt für Takt erwarte ich, dass die 6600 pro Pixelpipe ein wenig schneller ist als 6800.
Note: 1+
Zitat: das mit dem SLI is sicher ne tolle Sache (like Voodoo2 anno 19xx *g*), nur stell ich mir die Frage wie es mit der Belüftung der ersten karte laufen wird, da die zweite ja direkt davor sitzt, bekommt die dann noch genu luft ?
bin mal gespannt wie das in der Praxis an nem heißem Sommertag läuft *gg*
Note 1++
@Gast
Search trough the net and you will finde the pictures.
There is enough room between the cards-shuld be 5cm.
@IVN
You can send 256 Bit over a 128bit width pipe in 2 clocks, with older SDR technology, yes, but DDR allows you to transfer 2 signals (= 2 bit) within one clock cycle over a 1 bit wide pipe, thus 256bit over a 128bit pipe in one clock cycle.
Yes, in your example, the memory connection is 64 bits wide, and to transfer 3200MB of data per second, it needs an effective speed of 400MHz (3200M*8/64bit)
However, it only runs at 200MHz, because it can effectively transfer 128bit per clock cycle even thpough it's only 64Bit wide thanks to it's DDR technology, which gives you the effective 400MHz speed at the 64bit pipe to transfer the 3200MB/s...
ravage
2004-08-13, 09:36:26
Vorletzter Absatz:
[...]Zwischen der GeForce 6800GT und den neuen HighEnd-Karten um Radeon GeForce 6800 Ultra und Radeon X800 XT-PE wird zwar[...]
Ist Da nicht ein Radeon zu viel?
An Sonsten: Toller Artikel.
@aths
I really don't understand what are you tallking about.The mem. con. has an wigth of 128 bit,that means 128 bit can be sent trough him in one clock.Da DDR-Technologie genutzt wird (Double Data Rate) kann man pro Takt das doppelte übertragen.
Only memory can work in DDR mode,but this means that the mem. chip on the modul (exampel ddr 3200MB aka 400MHz) is working with 200 MHz but the information can be read and wrote in one clock. Die Caches sind entsprechend breit angebunden. Wozu sonst DDR?
@aths
128 bit * 1000Mhz /8 =16GB
And you said that the mem. con. is logically 256 bit width.That would mean:256 bit * 1000mhz /8 =32GB :|
The mem. con. would be 256 bit width (logically) only if you count the mem. speed at 500mhz (real speed).
@aths
This the reason why i think that the mem. con. is 128 bit width.
If the execution unites in the GPU need 256 bit amount of data,then they would have to wait 2 clocks for the mem. con. to read them from the memory chips.From the memory chips (place A) to the execution us.(place B) the m.c. can transport in 1 clock only 128 bit.And what happens if you have to read from the memory 100 clocks (as amount of time ) without writeing anything in it.Than for all that time the mem. con. is 128 bit width .This means that the mem .con. can transport in one direction only 128 bits=it's 128 bit width.
For an mem. con. to be 256 bit width it must be capable to transport 256 bits in one given direction in one clock.
@aths
The mem. con. would be 256 bit width (logically) only if you count the mem. speed at 500mhz (real speed).
Well, exactly, we are always talking about the "real" clock frequency/speed as you call it...
eg the 6600GT has a 500MHz mem clock, DDR400 has a 200MHz clock...
GloomY
2004-08-13, 16:09:18
@aths
128 bit * 1000Mhz /8 =16GB
And you said that the mem. con. is logically 256 bit width.That would mean:256 bit * 1000mhz /8 =32GB :|
The mem. con. would be 256 bit width (logically) only if you count the mem. speed at 500mhz (real speed).Of course real speed. Everything else is bullshit.
A 128 bit wide interface (which means 128 data lines) operating with a certain clock and a DDR protocoll makes the interface appear logically 256 bits wide. The clock does not change when going from SDR to DDR.
btw: Why english if you are capable of speaking german?
Quasar
2004-08-13, 16:10:56
The mem. con. would be 256 bit width (logically) only if you count the mem. speed at 500mhz (real speed).
Of course, because that is it's physically existing clock speed. It is able to initiate a transfer 500 Million times per second (500MHz).
If there's enough data to be written or to be read, it can (actually it does it automatically) read or write double it's physical bus width of 128 bit, hence the term DDR. If there's because of some cache problem or god knows what, only say, 96 Bits of data to be transferred at a given time, they can be transferred in the transaction occuring at the rising signal flank, leaving 32 bits unuse, but the dependant transfer on the falling edge of the signal is wasted also - this is the difference between a "real" 256 bit wide interface and a logically 256 bit wide one.
Neither clock speed goes up (a 1000MHz part could do 1000 million independent transfers of 128 bit each per second), nor is the bus actually 256 bit wide.
edit:
Damn, way to slow....
Leonidas
2004-08-13, 16:31:15
Vorletzter Absatz:
[...]Zwischen der GeForce 6800GT und den neuen HighEnd-Karten um Radeon GeForce 6800 Ultra und Radeon X800 XT-PE wird zwar[...]
Ist Da nicht ein Radeon zu viel?
An Sonsten: Toller Artikel.
Gefixt.
Quasar, nach den unabhängigen Transfers kannst du leider auch nicht gehen.
Um es mal ganz klar zu formulieren: NV40 hat ein 4x64bit DDR Speicherinterface, pro Takt werden 4x128bit, also 512bit übertragen, und weil die Burst Length bei GDDR3 gleich 4 ist, ist die minimale Blockgröße 256bit.
Der Speichercontroller überträgt also in zwei Takten vier jeweils 256bit große Blöcke (maximal).
Quasar
2004-08-13, 18:52:47
Quasar, nach den unabhängigen Transfers kannst du leider auch nicht gehen.
Ähm, ja, jetzt fällt's mir auch auf - auch bei einem echten 256Bit-Inferface wären in meinem Beispiel 160Bit verschwendet worden.
@aths
128 bit * 1000Mhz /8 =16GB
And you said that the mem. con. is logically 256 bit width.That would mean:256 bit * 1000mhz /8 =32GB :|
The mem. con. would be 256 bit width (logically) only if you count the mem. speed at 500mhz (real speed).Die 6600 GT hat 500 MHz DDR-RAM, nicht 1000 MHz. 256 Bit × 500 MHz = 16 GB/s.
@aths
Read my second posting and you will see that your 256 bit mem.con. isn't 256 bit after all.An 256 bit mem.con. must be able to send 256 bit in every direction in one clock (DDR mode).This one (m.c. in 6600gt GPU) can't do that,so it's an 128 bit.
Ach ja, antwortet IVN doch in Deutsch, dann kann es jeder lesen.
Zu den ROPs:
NV40 kann:
NoAA 2xAA 4xAA
Z/Stencil 32 16 8
Color + Z/S 16 16 8
Blending 8 8* 8*
FP16 Blending 4 4* 4*
(Pixel pro Takt)
* gilt nur, wenn im Framebuffer alle zum Pixel gehörigen Samples identisch sind.
Ich fände es ziemlich wahrscheinlich dass NV43 genau die Hälfte davon schafft.
For an mem. con. to be 256 bit width it must be capable to transport 256 bits in one given direction in one clock.
Das ist genau soviel wie der Memory Controller des NV43 schafft. 4x64bit pro Takt.
@Xmas
Can it take that much (256bit)data from,or write (256bit) to the memory in one clock.
I think not.It can read (128)and write (128) in the memory in one clock.But this doesen't makes it a 256 bit controler.
The width is still 128 bit. :wink:
Nein, der Controller kann pro Takt entweder
256 bit lesen
128 bit lesen, 128 bit schreiben
256 bit schreiben
marlurau
2004-08-13, 21:14:11
Ist ja prima,diese Anpassungsfähigkeit.
Gibts dies erst bei den NV 40er, oder schon früher?
Quasar
2004-08-13, 21:22:00
Bei nVidia seit dem nV20 (GeForce3), zeitlich gesehen. Technisch ab dem nV17. Matrox hatte einen Urahn dieser Technologie im G200-Chip und ATi hielt sich vor der R8500 ziemlich bedeckt, spätestens diese hat aber einen unterteilten Speichercontroller gehabt (2x64Bit, IIRC).
Natürlich waren die jeweiligen Controller 'anders' unterteilt, da sie andere Bitbreiten aufwiesen.
Allerdings hat jeder Kanal "seinen" Speicherbereich, auf den kein anderer Kanal zugreifen kann. Deswegen müssen die Daten intelligent auf die Bereiche verteilt werden.
@Xmas
How is that posible??
A mem.con. could do that,but how can the DDR memory work under these conditions.128bit read+128 write and the mem. works in the DDR mode.
But 256 bit(only) read OR 256 bit(only) write,than the memory is working in SDR mode,or something like that.
It is not reading and writeing in the same clock,so it is not working in DDR mode.
MadManniMan
2004-08-14, 00:34:26
aths:
Ich denke das Grundsatzproblem in dieser X*Ybit Diskussion, ist daß du dich mit "4*128bit" von der üblichen Nomenklatur löst, die DDR nicht mit einberechnet.
Es ist ganz einfach üblich, beim GeForce3 von 4*32bit und beim Radeon9700 von 4*64bit zu reden. Die Radeon9500 Pro hatte ein äquivalent aufgeteiltes Interface - dort sprach man von 2*64bit, von daher würde ich darum bitten, das im Artikel anzupassen!
Nochwas:
In wie weit ist die Kompression verbessetr worden? Ein optimierter Algorithmus?
GloomY
2004-08-14, 01:31:56
Quasar, nach den unabhängigen Transfers kannst du leider auch nicht gehen.
Um es mal ganz klar zu formulieren: NV40 hat ein 4x64bit DDR Speicherinterface, pro Takt werden 4x128bit, also 512bit übertragen, und weil die Burst Length bei GDDR3 gleich 4 ist, ist die minimale Blockgröße 256bit.Ja, denn bei GDDR3 können (Read-)Bursts nicht abgebrochen werden, so wie das z.B. bei DDR1 oder 2 oder Fall ist. Dort kann z.B. der Controller bei einer BL von 8 nach 4 Takten schon dicht machen, wenn er will (und der Speicher kann, d.h. tRAS genügend niedrig).
@Xmas
How is that posible??
A mem.con. could do that,but how can the DDR memory work under these conditions.128bit read+128 write and the mem. works in the DDR mode.
But 256 bit(only) read OR 256 bit(only) write,than the memory is working in SDR mode,or something like that.
It is not reading and writeing in the same clock,so it is not working in DDR mode.Ich behaupte einfach mal, dass es einfach zwei 64 Bit breite (physische Datenleitungen) unabhängige Controller sind. D.h. für jeden Controller kann man 128 Bit pro Takt schreiben oder lesen. Wenn beide Controller gleichzeitig lesen, sind das eben 256 Bit pro Takt. Wenn einer liesst und der andere schreibt, dann eben 128 Lesen und 128 Schreiben. Und wenn beide Schreiben, dann eben 256 Bit pro Takt Schreiben =)
MadManniMan
2004-08-14, 01:39:04
Ich behaupte einfach mal, dass es einfach zwei 64 Bit breite (physische Datenleitungen) unabhängige Controller sind.
Hm, sehr schön, du nimmst mir quasi die Worte aus dem Mund ;) :up:
Der "klassische" CBMC hatte ja 4*32 Leitungen - von daher sollte imho die anzahl an Datenleitungen auch als Referenz für die Nomenklatur herangezogen werden.
Ailuros
2004-08-14, 13:46:13
Ja ich hab gelesen dass ein ROP relevanter Artikel gerade gebacken wird, aber wie genau ist das Zeug jetzt mit dem ROP-Gewarkel?
Handelt es sich um ROPs die sich auf C- und Z-ROP aufteilen, oder doch um getrennte C-/Z-ROPs?
Im Grunde waere ja die angegebene Anzahl von ROPs eigentlich egal, solange fuer NV3x nicht auch 16 ROPs angegeben wurden.
Ja ich hab gelesen dass ein ROP relevanter Artikel gerade gebacken wird, aber wie genau ist das Zeug jetzt mit dem ROP-Gewarkel?
Handelt es sich um ROPs die sich auf C- und Z-ROP aufteilen, oder doch um getrennte C-/Z-ROPs?Es handelt sich wahrscheinlich um ROPs, die 2x auf Z/S testen oder statt 1x Z/S zu testen alternativ die Farbe mit durchschieben können. Nvidias Diagramme sind leider nicht sehr hilfreich und widersprechen einigen Tatsachen.
Im Grunde waere ja die angegebene Anzahl von ROPs eigentlich egal, solange fuer NV3x nicht auch 16 ROPs angegeben wurden. Streng genommen hat auch NV40 nur 8 komplette ROPs, wie Xmas' Einwand mit den Alphablending-Einheiten zeigt. Kommende Woche versuche ich, bei NV einige fehlende Details in Erfahrung zu bringen.
aths:
Ich denke das Grundsatzproblem in dieser X*Ybit Diskussion, ist daß du dich mit "4*128bit" von der üblichen Nomenklatur löst, die DDR nicht mit einberechnet.
Es ist ganz einfach üblich, beim GeForce3 von 4*32bit und beim Radeon9700 von 4*64bit zu reden. Die Radeon9500 Pro hatte ein äquivalent aufgeteiltes Interface - dort sprach man von 2*64bit, von daher würde ich darum bitten, das im Artikel anzupassen!Ich denke drüber nach.
Nochwas:
In wie weit ist die Kompression verbessetr worden? Ein optimierter Algorithmus? Nein, mit Magie.
Natürlich wird es am Komprimierungsalgorithmus liegen. Theoretisch gibts Farbkomprimierung ohne AA schon seit GF FX, nur klappt das dort kaum. Einen echten Beweis habe ich allerdings noch nicht gesehen. Zöcky müsste mal den Archmark erweitern, so dass ein mal CC zuschlagen könnte, und einmal sicher verhindert wird.
@Xmas
How is that posible??
A mem.con. could do that,but how can the DDR memory work under these conditions.128bit read+128 write and the mem. works in the DDR mode.
But 256 bit(only) read OR 256 bit(only) write,than the memory is working in SDR mode,or something like that.
It is not reading and writeing in the same clock,so it is not working in DDR mode.
Du gehst scheinbar davon aus dass DDR bedeute, in einem Takt gleichzeitig zu lesen und zu schreiben. Das ist nicht der Fall. DDR bedeutet, in einem Takt (bei steigender und fallender Flanke) zwei Bits pro Datenleitung in eine Richtung zu übertragen.
Ailuros
2004-08-15, 02:20:59
Es handelt sich wahrscheinlich um ROPs, die 2x auf Z/S testen oder statt 1x Z/S zu testen alternativ die Farbe mit durchschieben können. Nvidias Diagramme sind leider nicht sehr hilfreich und widersprechen einigen Tatsachen.
Streng genommen hat auch NV40 nur 8 komplette ROPs, wie Xmas' Einwand mit den Alphablending-Einheiten zeigt. Kommende Woche versuche ich, bei NV einige fehlende Details in Erfahrung zu bringen.
Fair enough :)
B3D´s NV40 review hat uebrigens ein Diagramm auf der Pixel-ROP Seite, aber ich hab keine Ahnung ob es von NV stammt.
Fragen hilft mir auch nicht viel; ich hab immer noch keine Antwort bekommen ob die 6800nonU nun einen 5- oder 6-way MIMD hat.... ;(
Fair enough :)
B3D´s NV40 review hat uebrigens ein Diagramm auf der Pixel-ROP Seite, aber ich hab keine Ahnung ob es von NV stammt.Hat wavey (wie auch einige Tabellen) aus dem NV-Material abgemalt.
Ailuros
2004-08-15, 18:59:00
Hat wavey (wie auch einige Tabellen) aus dem NV-Material abgemalt.
Dann ist das Quellen-Material tatsaechlich zu ungenau/zweideutig. Danke.
MadManniMan
2004-08-16, 14:44:45
Ich denke drüber nach.
Freut mich :up:
Nein, mit Magie.
Ein zynischer aths - erlebt man selten :bäh:
Natürlich wird es am Komprimierungsalgorithmus liegen. Theoretisch gibts Farbkomprimierung ohne AA schon seit GF FX, nur klappt das dort kaum. Einen echten Beweis habe ich allerdings noch nicht gesehen. Zöcky müsste mal den Archmark erweitern, so dass ein mal CC zuschlagen könnte, und einmal sicher verhindert wird.
Hm, dem muß ich mal nachgehen... ich takte mal meine FX5800 und meine Ti4200 gleich - wenn es klappt.
IIRC war ja die CC die einzige Verbesserung am AA gegenüber dem NV2X - den Filter on Scanout bei 256MB NV38 Karten mal ausgenommen.
Quasar
2004-08-17, 09:16:20
Auch der nV25 konnte schon Filter@Scanout, wenn ich mich recht erinnere. Zumindest deutete das Problem, welches viele Reviewer anfänglich hatte, ordentliche gegenaliasiert Screenshots einzufangen, obwohl laut deren Bekunden in-Game AA wirksam war, stark darauf hin.
IIRC wurde das später auch öffentlich bestätigt.
MadManniMan
2004-08-17, 16:14:01
Auch der nV25 konnte schon Filter@Scanout, wenn ich mich recht erinnere. Zumindest deutete das Problem, welches viele Reviewer anfänglich hatte, ordentliche gegenaliasiert Screenshots einzufangen, obwohl laut deren Bekunden in-Game AA wirksam war, stark darauf hin.
Ich weiß, dort aber nur bei 2*AA. Erst der NV38 hatte dies IIRC auch bei 4*AA.
mapel110
2004-08-17, 16:31:01
Ich weiß, dort aber nur bei 2*AA. Erst der NV38 hatte dies IIRC auch bei 4*AA.
für 4xAA waren ja auch drigend 256 mb Ram von nöten, damit das mit dem scanout etc funzte?!
MadManniMan
2004-08-17, 17:03:23
für 4xAA waren ja auch drigend 256 mb Ram von nöten, damit das mit dem scanout etc funzte?!
Richtig :)
Quasar
2004-08-17, 18:30:23
In 1024 bsw. eigentlich nicht. Erst in 1600x1200 wird die Gesamtgröße aller benötigten Frame-, Z- und MS-Buffer so groß, daß bsw. Vertexbuffer o.ä. kaum noch Platz im VRAM haben.
MadManniMan
2004-08-17, 19:08:50
Wie dem auch sei, erst bei 256MB Karten überwandt sich NV, FoS auch für 4*AA zu benützen, gell?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.