Eric Demers ueber R6x0 bei B3D

[Ailuros]

http://www.beyond3d.com/content/interviews/39

Kommentare bitte ;)

[Sterem]

We also had some last minute performance possibilities, which is always incompatible with stability, and we did not have enough time to get those tested and integrated in time for launch. We see in the latest driver, some 2x to 3x improvement in adaptive AA performance, for example, which is great but came later than I would have liked. But, I’ll admit, there’s so much to do still, that I haven’t really spent that much time on reviews and such. The reality is that I expect things to continue to improve and be much better in a few months.

Aha in paar Monaten ok.:mad:

[deekey777]

http://www.beyond3d.com/content/interviews/39/3
Why go superscalar in the ALU structure? R580's fragment shader core is a result of shader analysis for instruction properties, so is the superscalar design in R600 an extension of that work?

Yes, it was a result of our continue analysis of shaders. R5xx what pretty much a direct reflection of DX9 SM2/3, with some tweaks for enhancements. The R600 has a scalar design structure, which is optimized for what we see in current shaders and what we see in upcoming shaders. More and more work gets done in scalar paths and focusing on this gives you the best flexibility to address that. Basically, you can do vector perfectly and deal with any scalar paths too. As well, from a physical standpoint, focusing on a scalar design is significantly easier than having to deal with vector datapaths.
Aha...

Also, on the feature side, we weren’t able to expose the adaptive edge detect CFAA modes to the public, or even to the press, until very late in the review process. This means that most reviewers did not have a chance to look at the amazing quality this mode offers – There is nothing comparable to it out there.
Die, die EDCFAA gesehen haben, waren davon alles andere als begeistert.
http://www.digit-life.com/articles2/video/r600-part4.html

[robbitop]

Die, die EDCFAA gesehen haben, waren davon alles andere als begeistert.
http://www.digit-life.com/articles2/video/r600-part4.html
1.haben sie nicht mal die Funktionsweise von ED richtig erkannt (was eigentlich nach ein paar Tests klar sein sollte)
2.haben sie es in dem Test gar nicht richtig untersucht. ED ist wirklich gut. Aber eben zu teuer.

@AiL
Der Tenor von Eric ist sehr positiv und er klingt auch wie ein ehrlicher Mensch. Aber andererseits wird wohl niemand die Produkte seiner eigenen Firma oeffentlich schlechtreden.

Glaubst du ihm etwa? Ich dachte das Ding seit total verbuggt und nur durch hervorragende Treiberarbeit einigermassen stabil?
Jedenfalls wirken einige Bottlenecks in dem Design so fies, dass sich R600 oft nicht von R580 absetzen kann.
Erwartest du da eine deutliche Steigerung durch Treiber?
IMO kann man die Fuellrate und die komischen ROPs wohl kaum durch Treiber drastisch ausgleichen.

[mapel110]

We also had some last minute performance possibilities, which is always incompatible with stability, and we did not have enough time to get those tested and integrated in time for launch. We see in the latest driver, some 2x to 3x improvement in adaptive AA performance, for example, which is great but came later than I would have liked. But, I’ll admit, there’s so much to do still, that I haven’t really spent that much time on reviews and such. The reality is that I expect things to continue to improve and be much better in a few months.

Aha in paar Monaten ok.:mad:
Ergänzend...

How would you describe the maturity of R6 drivers at this point and how "target rich" the optimization opportunities still are going forward?

I think we have a very dedicated and excellent set of engineers working on our drivers. However, given a new operating system, a new DX, a new OpenGL driver and a whole new architecture, we got the perfect storm!

Okay, neuer opengl-Treiber. Aber an dem sind sie auch schon seit Jahren dran und die restlichen Probleme hatte die Konkurrenz auch und war dennoch ein halbes Jahr früher mit besseren Treibern am Start.

I think that the drivers are very stable and give users a good experience. But when it comes to performance, there’s still a lot to optimize for. And it will take time to exploit the full performance potential of the hardware. They have done what was required, which is give the best $399 part, but there’s so much more to do… So I would say that a lot of progress has been made, but things are still “green”, especially on the DX10 front.
Bei DX10 noch mehr als bei DX9. Aha...

[reunion]

Versteht das jemand?

Does a 512-bit bus require a die size that's going to be in the neighbourhood (or bigger) of R600 going forward?

No, through multiple layers of pads, or through distributed pads or even through stacked dies, large memory bit widths are certainly possible. Certainly a certain size and a minimum number of “consumers” is required to enable this technology, but it’s not required to have a large die

Auch das was er zum Threading-Zeug sagt ist sehr interessant, da scheint sich bei R600 einiges getan zu haben.

[Gast]

Ich glaube nicht das der Herr wirklich "ehrlich" in diesem Interview war. Liest sich teilweise wie eine Marketing Mappe, Fragen auszuweichen mit allgemeinen Floskeln, hät er auch gleich gar nix zu sagen können.

Treiber..., ich gehe davon aus das es besser werden wird aber nicht wie man sich das auf Seiten der User erhofft und man irgendwann einmal eine GTX versägen wird bzw. sich von einer GTS absetzen kann, MIT AF/AA.

Interessant ist der Kommentar zum 512-Bit SI, das wohl nicht so kompliziert/teuer ausgefallen ist wie von allen Seiten erwartet. Genauso ist die größe der Tesselation Einheit wohl nicht so groß, was sie evtl. nicht so teuer macht. Und wenn nV gar keine spezialisierte Einheit in dieser hinsicht hat, kann auch eine rudimentäre billige Einheit 50x so schnell sein wie die Konkurrenz.

Naja ist auch absolut Nebensache da die Einheit unter DX10 nicht angesprochen werden kann und unter OpenGL wirds keiner machen, wer auser Carmack entwickelt noch unter OpenGL?

Schade auch das man ihn nicht auf den Unterschied der polygon rates zwischen R600 und RV630? angesprochen hat ;) [700Mpoly/sec vs 675Mpoly/sec]

[mapel110]

Hm, also ich versteh das so, dass ein 512 Bit SI kein besonders großen Die des Chips benötigt, um eben angestöbselt zu werden. Man kann Dies stapeln, man kann extra pads basteln, an denen man connected, oder mehrere Lagen von pads.

Worauf man achten muss ist, dass alle Speicherkanäle auch genutzt werden. "consumers" eben.
:uponder:

[reunion]

@AiL
Der Tenor von Eric ist sehr positiv und er klingt auch wie ein ehrlicher Mensch. Aber andererseits wird wohl niemand die Produkte seiner eigenen Firma oeffentlich schlechtreden.

Glaubst du ihm etwa? Ich dachte das Ding seit total verbuggt und nur durch hervorragende Treiberarbeit einigermassen stabil?
Jedenfalls wirken einige Bottlenecks in dem Design so fies, dass sich R600 oft nicht von R580 absetzen kann.
Erwartest du da eine deutliche Steigerung durch Treiber?
IMO kann man die Fuellrate und die komischen ROPs wohl kaum durch Treiber drastisch ausgleichen.

Time will tell. Es ist jedenfalls logisch, was er sagt. Stabilität geht natürlich vor Performance und die Treiber machen ja wirklich alles andere als eine ausgereiften Eindruck. Wenn diese Leistungssteigerung um Faktor 2-3 mit AAA, die er explizit erwähnt, nicht völlig aus der Luft gegriffen ist, dann sind vielleicht doch die Treiber, und nicht die Hardware verbuggt. Theoretische Daten sind zwar schön, aber im Endeffekt nur Schall und Rauch.

[reunion]

Ich glaube nicht das der Herr wirklich "ehrlich" in diesem Interview war. Liest sich teilweise wie eine Marketing Mappe, Fragen auszuweichen mit allgemeinen Floskeln, hät er auch gleich gar nix zu sagen können.


Der Mann hat es sicher nicht nötig, einen auf Marketing zu machen. Es gibt bei ATi wohl kaum jemanden, der mehr Ahnung von der Materie hat als Sir Eric Demers.

Hm, also ich versteh das so, dass ein 512 Bit SI kein besonders großen Die des Chips benötigt, um eben angestöbselt zu werden. Man kann Dies stapeln, man kann extra pads basteln, an denen man connected, oder mehrere Lagen von pads.

Worauf man achten mussist, dass alle Speicherkanäle auch genutzt werden. "consumers" eben.
:uponder:

Ja, nur erscheint mir das irgendwie unlogisch.

[Gast]

Wenn diese Leistungssteigerung um Faktor 2-3 mit AAA, die er explizit erwähnt, nicht völlig aus der Luft gegriffen ist, dann sind vielleicht doch die Treiber, und nicht die Hardware verbuggt.

wenn man TRSSAA mit TRMSAA aka EATM ersetzt sollte das nicht gerade schwer sein.

[robbitop]

Der Mann hat es sicher nicht nötig, einen auf Marketing zu machen. Es gibt bei ATi wohl kaum jemanden, der mehr Ahnung von der Materie hat als Sir Eric Demers.

Ich weiss zwar nicht, warum die Leute ihn mit Sir ansprechen, aber erzaehlen wird er oeffentlich sicher nichts negatives.

Ich vermute, dass sicher noch etw Potenzial im Design steckt.
Aber wenn das Ding wirklich so verbuggt ist, wie AiL angedeutet hat (und die ROP Ergebnisse unterstuetzen diese These), dann wird in einigen Situationen nicht viel zu machen sein. Das mit den ROPs gibt Eric im Interview auch zu. Und auch, dass sie 2005 entschieden haben die ROPs und TMUs nicht so hoch zu skalieren (offenbar war der 65 nm Prozess urspruenglich fuer R600 geplant).

Dass Eric immer wieder auf die Tex:ALU Rate zielt und andeutet, dass der G80 zuwenig Bandbreite fuer all die Texturfuellrate haben, stimmt zwar, aber dabei verschweigt er natuerlich die Auswirkungen bei 3dcenter-approved AF. Das kostet naemlich so gut wie nur Fuellrate oben drauf. Und genau das juckt den G80 kaum (im Gegensatz zur R600).

Naja Spekulatius schmeckt am besten zu Weihnachten...

[Mr. Lolman]

, aber dabei verschweigt er natuerlich die Auswirkungen bei 3dcenter-approved AF.

Ist denn AIlow nun plötzlich nicht mehr 3dcenter approved?

[dildo4u]

Doch er meint ja AILow siehe hier die Verluste sind beim 16XAF mit AILow(AF Optemierungen) schon wirklich immens 28-45%.

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_2900_xt/8/#abschnitt_aa_und_af_skalierung

[Ailuros]

@AiL
Der Tenor von Eric ist sehr positiv und er klingt auch wie ein ehrlicher Mensch. Aber andererseits wird wohl niemand die Produkte seiner eigenen Firma oeffentlich schlechtreden.

So bloed waere keiner.

Glaubst du ihm etwa? Ich dachte das Ding seit total verbuggt und nur durch hervorragende Treiberarbeit einigermassen stabil?

Es muss wohl einen Grund geben warum er dem Treiberteam so hinterhetzt oder?

Jedenfalls wirken einige Bottlenecks in dem Design so fies, dass sich R600 oft nicht von R580 absetzen kann.
Erwartest du da eine deutliche Steigerung durch Treiber?
IMO kann man die Fuellrate und die komischen ROPs wohl kaum durch Treiber drastisch ausgleichen.

Steigerungen durch Treiber gab es auch auf der 8500. Wieso fragst Du mich ueberhaupt, wenn Du schon selber Deine eigene Frage im ersten Paragraphen oben beantwortet hast?

[Ailuros]

Time will tell. Es ist jedenfalls logisch, was er sagt. Stabilität geht natürlich vor Performance und die Treiber machen ja wirklich alles andere als eine ausgereiften Eindruck. Wenn diese Leistungssteigerung um Faktor 2-3 mit AAA, die er explizit erwähnt, nicht völlig aus der Luft gegriffen ist, dann sind vielleicht doch die Treiber, und nicht die Hardware verbuggt. Theoretische Daten sind zwar schön, aber im Endeffekt nur Schall und Rauch.

Und die letzte Verspaetung kam weil die 2900 zeitgleich zu mainstream/low-end GPUs angekommen ist ja? Gibt es eine halbwegs logische Erklaerung von Euch Kerlen fuer diese, oder hatte AMD einfach nur Lust weniger fertige Produkte zu verkaufen?

Es stimmt zwar schon dass sie noch weitere Leistung aus zukuenftigen Treibern quetschen koennen, aber was fuer Umwege der Treiber dann gehen wird geht wohl auch keinen an.

Hoffnung stirbt als letzte selbst theoretisch.

[Ailuros]

Ich weiss zwar nicht, warum die Leute ihn mit Sir ansprechen, aber erzaehlen wird er oeffentlich sicher nichts negatives.

Weil er bei B3D als sireric auftaucht.

Ich vermute, dass sicher noch etw Potenzial im Design steckt.
Aber wenn das Ding wirklich so verbuggt ist, wie AiL angedeutet hat (und die ROP Ergebnisse unterstuetzen diese These), dann wird in einigen Situationen nicht viel zu machen sein. Das mit den ROPs gibt Eric im Interview auch zu. Und auch, dass sie 2005 entschieden haben die ROPs und TMUs nicht so hoch zu skalieren (offenbar war der 65 nm Prozess urspruenglich fuer R600 geplant).

R6x0 war schon immer fuer 80nm geplant.

[Ailuros]

Der Mann hat es sicher nicht nötig, einen auf Marketing zu machen. Es gibt bei ATi wohl kaum jemanden, der mehr Ahnung von der Materie hat als Sir Eric Demers.

Die Wahrheit ist dass Eric ein zu netter Kerl ist und kein besonderes Talent hat sich als Marketing-Affe zu praesentieren. Und das spricht natuerlich fuer ihn und nicht gegen ihn.

Ja, nur erscheint mir das irgendwie unlogisch.

Bitte Anfuehrungsstriche beachten:

Certainly a certain size and a minimum number of “consumers” is required to enable this technology, but it’s not required to have a large die.

IMHLO meint er hier mit "consumers" Daten und keine Verbraucher. Anders so grosse Datenstroeme dass die Lese-Effizienz nicht mehr Bandbreite frisst als man eigentlich haben will.

Mehr oder weniger liegt seine Antwort hier versteckt:

The R600 uses an evolutionary approach to the memory controller with respect to the R5xx MC. We went fully distributed on both reads and writes, with arbitration decentralized to pairs of channels; also it supports full virtualization, including all elements of the windows advanced driver models. We went to 8channels of 64b data, giving the 512b memory subsystem. I think that this evolutionary approach actually allowed for a 512b interface to be built and used to our advantage. Without that, the complexity for physical layout would have been too substantial. We absolutely need to keep on optimizing its settings to get better performance out of current and future games. We’ve just started that work. The advantage of being flexible and programmable is that you can adapt to many different situations and get great performance. The disadvantage is that doing that work requires post silicon work and a team to optimize. And it’s not an easy or quick thing to do – I expect further performance improvements as time goes on and as the teams get to know this new architecture.

[Ailuros]

Was there ever a set of simulations run comparing R600 + R580 RBEs vs the final design, and if so what were the interesting datapoints that came out?

Yes, there were hundreds. Yes, a few things came out in the final design, but, in general, it was as expected. -- Resolve was moved into the shader, so that can't really get compared.

How exactly does the fast path work for passing back MSAA sample data to the shader core?

Secret.

:biggrin:

http://forum.beyond3d.com/showpost.php?p=1020296&postcount=71

[Gast]

Der Mann hat es sicher nicht nötig, einen auf Marketing zu machen. Es gibt bei ATi wohl kaum jemanden, der mehr Ahnung von der Materie hat als Sir Eric Demers.
Darum geht's nicht. Auch diese Leute haben NDAs und konkrete Vorgaben, was sie wie sagen dürfen.

[BlackBirdSR]

da fage ich mich, warum keiner vorher an Redundanz gedacht hat. Da erklärt sich gleich, warum der Chip gar so komplex ist.

[robbitop]

Ist denn AIlow nun plötzlich nicht mehr 3dcenter approved?
AI-Low war nie 3dcenter approved.
Von der Lodpraezision und der AF-Blume schon, aber vom Flimmern bei HF Texturen definitiv nicht.

So oder so kostet AF beim R600 sehr viel.

[robbitop]

Wieso fragst Du mich ueberhaupt, wenn Du schon selber Deine eigene Frage im ersten Paragraphen oben beantwortet hast?
Weil es nur meine Meinung ist, die aber obsolet sein kann. Du bist ja deutlich besser informiert als ich. :)

Weil er bei B3D als sireric auftaucht.
Das ist mir bekannt. Jedoch ist "Sir" ja ein Adelstitel. Ich bezweifle, dass er wirklich einen hat. ;)



R6x0 war schon immer fuer 80nm geplant.
Das klingt im Interview aber ganz anders.

[mapel110]

da fage ich mich, warum keiner vorher an Redundanz gedacht hat. Da erklärt sich gleich, warum der Chip gar so komplex ist.
Glaubst du wirklich, dass G80 keine redundanten Schaltkreise hat? Also ich nicht. Und zum Umfang der Redundanz kann man nur spekulieren, bei beiden IHVs.

[BlackBirdSR]

Glaubst du wirklich, dass G80 keine redundanten Schaltkreise hat? Also ich nicht. Und zum Umfang der Redundanz kann man nur spekulieren, bei beiden IHVs.

Natürlich glaube ich auch, dass der G80 eine Menge Redundanz aufweist.
Aber wenn ATI das bis ins Extreme getrieben hat, sind nicht wenige dieser Transistoren gar nicht unbedingt im Einsatz.
Sollten sie aber trotzdem mit dem Taktisgnal versorgt werden (müssen?), ershließt sich gleich eine neue Quelle für die extrem hohen Verbrauchswerte.

Gerade bei einem neuen, nicht ausgetesteten Prozess ist Redundanz überlebenswichtig. Ich denke, dass Nvidia viel besser einschätzen konnte, wie die Yields ausfallen.

[Ailuros]

Das klingt im Interview aber ganz anders.

AFAIK 80nm....aber....

Apparently, the first spin of R600 silicon could only communicate over the debugging interface. While the upside is that the chip wasn't totally dead, this is not a good problem to have.

http://www.anandtech.com/video/showdoc.aspx?i=2988

Ich bin mir sicher dass Du den Zeitpunkt des ersten spins einschaetzen kannst; von da ab haette es genug Zeit gegeben auf 65nm umzusteigen und nein die damaligen schlechten yields des Prozesses haetten den chip wohl nicht weiter verzoegert. Es haette sogar sein koennen dass das Resultat frueher produktionsreif gewesen waere und man eben dann noch auf bessere yields haette warten muessen.

NV30 kam Mitte Sommer 2002 total tot vom Labor zurueck (nichtmal durchs debugging interface erreichbar) und dennoch schaffte NV mit extremem Druck diese Missgeburt in Q1 2003 auf die Regale zu bringen.

Und nein bevor es jemand falsch versteht, die zwei sind nicht vergleichbar. Ich meine nur dass es Zeit genug gab die richtige Entscheidung zu treffen.

[Ailuros]

Gerade bei einem neuen, nicht ausgetesteten Prozess ist Redundanz überlebenswichtig. Ich denke, dass Nvidia viel besser einschätzen konnte, wie die Yields ausfallen.

Im Fall von NVIDIA kam IMHO die erste G80(NV50)/90nm Fehlgeburt zum Vorschein die aber nie den Bereich eines Simulators verlassen hat. Selbst mit nur 500MHz und keine extravagante shader domains wie heute, verbratete das Ding eine Unmenge an Strom. Es wurde die G71 als Zwischenschieber geboren und da die Resultate des Simulators mit den "Handarbeit-ALU-Ultra-Frequenzen" keinen zu uebermaessigen Stromverbrauch fuer die Chipkomplexitaet und den Herstellungsprozess anzeigte, blieb man eben auf 90nm und sparte nochmal Zeit und Resourcen.

Anders: es ging NV in diesem Fall eher darum um einiges frueher als die Konkurrenz anzukommen als alles andere.

[reunion]

Und die letzte Verspaetung kam weil die 2900 zeitgleich zu mainstream/low-end GPUs angekommen ist ja? Gibt es eine halbwegs logische Erklaerung von Euch Kerlen fuer diese, oder hatte AMD einfach nur Lust weniger fertige Produkte zu verkaufen?

Es stimmt zwar schon dass sie noch weitere Leistung aus zukuenftigen Treibern quetschen koennen, aber was fuer Umwege der Treiber dann gehen wird geht wohl auch keinen an.

Hoffnung stirbt als letzte selbst theoretisch.

"Wir Kerle" haben nur etwas zur Disposition gestellt, nachdem Eric Demers ja ziemlich klar von einem reinen Treiberproblem spricht, und irrwitzige Leistungssteigerungen mit zukünftigen Treibern verspricht. Kein Grund gleich aus der Haut zu fahren.

[robbitop]

Da hast du ihn vermutlich falsch verstanden.


I did not mean to imply that. It's a good and reasonable design. The drivers are very stable and deliver the expected performance in many cases. There are certainly quite a few left to address. If someone is expecting a 2x boost in all apps, well, I'm sorry, but it won't happen. There's a couple of places where that kind of delta is possible, and a lot where 10 ~30% is possible too.

Man sollte schon mit einbeziehen, dass ein ATI Mann wohl kaum schlecht ueber sein Produkt reden darf.

Hier deutet er es an (natuerlich relativiert er es) auf die Frage, ob er am R600 Design was bereut oder verbessern wuerde:



Actually, yes, there is a lot. As I said, I've never had a project without regrets. Making those regrets public would only tarnish things without adding value.

Und natuerlich breitet er die Maengel in der Oeffentlichkeit nicht aus, da das dem Produkt schaden wuerde.

[Gast]

Ist denn AIlow nun plötzlich nicht mehr 3dcenter approved?

war es das jemals?

[Coda]

The first one prevents Z decompression from occurring as the stencil buffer gets used and updated. This was a prime cause of slowdowns on Doom3 for the R5xx, for example.
Also doch?

[Ailuros]

"Wir Kerle" haben nur etwas zur Disposition gestellt, nachdem Eric Demers ja ziemlich klar von einem reinen Treiberproblem spricht, und irrwitzige Leistungssteigerungen mit zukünftigen Treibern verspricht. Kein Grund gleich aus der Haut zu fahren.


Wie "irrwitzig" genau?

I did not mean to imply that. It's a good and reasonable design. The drivers are very stable and deliver the expected performance in many cases. There are certainly quite a few left to address. If someone is expecting a 2x boost in all apps, well, I'm sorry, but it won't happen. There's a couple of places where that kind of delta is possible, and a lot where 10 ~30% is possible too. But we are shipping a good product at an awesome price. People should buy based on current expectation (or near current), with the possibility of future improvements. From a functional aspect, there's more to do too (such as more custom filters, fixing some of the video stuff, etc... -- We have many features coming down the pipe). But we did ship a good product.

http://forum.beyond3d.com/showpost.php?p=1020346&postcount=86

Mir war von Anfang an klar was Eric mit seinen originalen Aussagen genau meinte, er setzt hier den Pegel genau an und es wurden nirgends grandiose Leistungsteigerungen versprochen oder sogar angedeutet.

Die Entscheidung das resolve in die shader zu werfen und seine Erklaerung machen mir persoenlich auch nicht viel Sinn. Dafuer machen die paar SW engineers die richtigen Notizen und Fragen in der Zwischenzeit.

[robbitop]

Er hat aber auch indirekt zugegeben, dass die Sampler unterdimensioniert sind und dass die Z-Rate der ROPs nicht ausreicht.

[reunion]

Da hast du ihn vermutlich falsch verstanden.


Vermutlich. Dieser Absatz erschien mir doch ziemlich eindeutig:

We also had some last minute performance possibilities, which is always incompatible with stability, and we did not have enough time to get those tested and integrated in time for launch. We see in the latest driver, some 2x to 3x improvement in adaptive AA performance, for example, which is great but came later than I would have liked. But, I’ll admit, there’s so much to do still, that I haven’t really spent that much time on reviews and such. The reality is that I expect things to continue to improve and be much better in a few months.

Die Entscheidung das resolve in die shader zu werfen und seine Erklaerung machen mir persoenlich auch nicht viel Sinn. Dafuer machen die paar SW engineers die richtigen Notizen und Fragen in der Zwischenzeit.

Ich glaube auch nicht, dass das resolve in den Shadern das Problem ist. So wie Eric das darlegt, macht das höchstens eine Unterschied bei sehr hohen Framraten. Eher scheinen die Sampler unterdimensioniert (wie robbitop schon sagte) - da scheint sich im Vergleich zu R580 kaum was getan zu haben. Er gibt selbst sogar an, dass er bei AA mit R600 einen größeren Leistungseinbruch erwartet als bei R580, was bei einer neuen Generation ziemlich seltsam anmutet. IMHO wurden bei diesem Design die falschen Prioritäten gesetzt.

[HOT]

In der letzten PCGH steht drin, dass die AA Kompression nicht richtig funktioniert. Da können die froh sein, überhaupt ein 512Bit Interface zu haben, da das einiges Kompensiert (was natürlich bei Weitem nicht reicht).
Würde das Problem behoben wäre das Teil plötzlich sogar sehr Konkurrenzfähig.
Zudem verbraucht ein G80 in Ultra Version mehr Strom als ein R600 und erreicht trotzdem nicht dessen Takt bei knapp weniger Komplexität. Es ist doch eigentlich wie immer, ATI kann mit den Treibern im Nachhinein deutlich Boden gut machen. Ich erinnere nur an den Speicherinterface-Bug.

[LovesuckZ]

Zudem verbraucht ein G80 in Ultra Version mehr Strom als ein R600 und erreicht trotzdem nicht dessen Takt.

Die Karte hat mehr Funktionseinheiten. Sie muss daher nicht den selben Takt erreichen.

[HOT]

Die Karte hat mehr Funktionseinheiten. Sie muss daher nicht den selben Takt erreichen.
Sie hat aber nicht dessen Komplexität.

[AnarchX]

Zudem verbraucht ein G80 in Ultra Version mehr Strom als ein R600 und erreicht trotzdem nicht dessen Takt bei knapp weniger Komplexität.

Unsinn, eine 8800Ultra ist teilweise mehr als doppelt so hoch getaktet:
1512MHz vs 742MHz ;)

NV kann halt den Takt selektiv höher ansetzen, wo man es braucht.
So weit ist man bei ATi noch nicht und muss primitiv mit der "Taktkeule"(:D) halt den ganzen Chip bearbeiten.

[Gast]

Sie hat aber nicht dessen Komplexität.

Das betrifft nur die Recheneinheiten, die weniger Komplex, dafür aber mit deutlich höhrerer Anzahl vorhanden sind.
Ansonsten hat der G80 mehr und in bestimmten Bereichen komplexere Einheiten. Daher wird kein hoher Takt benötigt.

[DaEmpty]

Ich hab den Threa auf B3D mal überflogen.
Wird irgendwo erklärt, warum der R600 mit MSAA so untergeht?
Immer wird nur geschrieben, der Shader-Resolve macht sich nur bei hohen Frameraten bemerkbar, mit 64Bit Framebuffer ist das AA wesentlich schneller wie bei den R5x0, etc.
Aber ich seh keine Erklärung wodran es liegt, dass die Karte mit MSAA teilweise hinter den Vorgänger zurückfällt...

[deekey777]

Ich hab den Threa auf B3D mal überflogen.
Wir irgendwo erklärt, warum der R600 mit MSAA so untergeht?
Immer wird nur geschrieben, der Shader-Resolve macht sich nur bei hohen Frameraten bemerkbar, mit 64Bit Framebuffer ist das AA wesentlich schneller wie bei den R5x0, etc.
Aber ich seh keine Erklärung wodran es liegt, dass die Karte mit MSAA teilweise hinter den Vorgänger zurückfällt...
Das Posting von nAo ist auch nicht uninteressant:
http://forum.beyond3d.com/showpost.php?p=1020463&postcount=99
AA resolve shoud be very fast on R600 given its 512 bits bus and its 64 processors.
At the same time I wonder how subsamples are fetched/decompressed and passed to the shaders core, if your AA resolve shader is just using TMUs to fetch those data I can see why it could be held back by the ALUs/TMUs ratio (in AA resolve shader you need a ALUs/TMUs ratio close to 1)

[DaEmpty]

Also limitieren die TMUs?
Irgendwie klingt mir das nicht ganz schlüssig, da man dafür nur Pointsamples braucht, von denen der R600 doch pro ROP 20 Stück pro Takt auslesen kann.

[tombman]

LOL!
--
Why did you eventually choose to not compete in the ultra-high end space, against 8800 GTX? Does AMD intend to compete for the single-card performance crown in the future?

Right now, our plan is to target the high end performance level with the R600, and the ultra high end will be covered by the crossfire configurations. Today, the crossfire R600 beats the high end ultra-super-expensive competition, by a significant margin, while being cheaper. For every price point we target, we always try to get the very best performance!
--

Und dann ist er aufgewacht und seine Hose war naß ;) Vielleicht sollte ihm mal jemand sagen, daß man auch eine GTX/Ultra in SLI betreiben kann :rolleyes:

[robbitop]

In der letzten PCGH steht drin, dass die AA Kompression nicht richtig funktioniert. Da können die froh sein, überhaupt ein 512Bit Interface zu haben, da das einiges Kompensiert (was natürlich bei Weitem nicht reicht).
Würde das Problem behoben wäre das Teil plötzlich sogar sehr Konkurrenzfähig.
Zudem verbraucht ein G80 in Ultra Version mehr Strom als ein R600 und erreicht trotzdem nicht dessen Takt bei knapp weniger Komplexität. Es ist doch eigentlich wie immer, ATI kann mit den Treibern im Nachhinein deutlich Boden gut machen. Ich erinnere nur an den Speicherinterface-Bug.
Das war eine Annahme von Demirug, die Carsten Spille aufgegriffen hat. Eric hat die Tests, die er dazu durchgefuehrt hat bereits als nicht aussagekraeftig bezeichnet.
Das Ding soll wohl an Z-Compares kranken. Und an unguenstigen Settings im programmierbaren Memorycontroller, was auch direkt mit den Z-compares zusammenhaengt.

Dass R600 keine Colorcompression hat, bezweifle ich, zumal Eric die auch indirekt erwaehnt hat. Auch das Resolve im Shader limitiert nicht so sehr, wie einige annehmen. Xmas hat das ja schonmal schoen vorgerechnet.

Am Ende des Tages ist auch das ein vielschichtiges Problem, welches sich nicht so einfach auf 2 Schlagworte beschraenken laesst.

[HOT]

Danke für die Aufklärung :)

[seahawk]

Langsam geht die 2900XT rivhtig ab

1920 x 1200 Xbit lab mit Cat 7,5 (einige Beispielbenches)

BattleField 2142
2900 XT - 74.5
8800GTS - 51.4

Call Of Juarez
2900 XT -36.9
8800GTS -29.2

FarCry Pier
2900 XT - 123.6
8800GTS- 83.5

FarCry Research
2900 XT - 161
8800GTS -102.5

FarCryHDR Research
2900 XT -83.9
8800GTS-78

Fear Extraction Point
2900 XT -42
8800GTS-36

Prey:
2900 XT - 51.6
8800GTS- 43.9

SplinterCell:
2900 XT - 54.6
8800GTS-46

Oblivion indoor:
2900 XT -71.1
8800GTS -66.3

Oblivion Outdoor:
2900 XT -50.1
8800GTS -47.1

X3 Reunion:
2900 XT -80.4
8800GTS -69.6

Company of Heroes
2900 XT -75.2
8800GTS-53.7

[Gast]

Ja toll, Werte ohne AA. Was soll man damit jetzt anfangen? Wäre außerdem schön, wenn du einen Link dazupacken würdest.

[PCGH_Carsten ohne Keks]

Das war eine Annahme von Demirug, die Carsten Spille aufgegriffen hat. Eric hat die Tests, die er dazu durchgefuehrt hat bereits als nicht aussagekraeftig bezeichnet.
Genau genommen sind wir unabhängig voneinander darauf gekommen. Sein Posting hier im Forum dazu habe ich gar nicht gesehen bis ich ihn auf diesen Umstand ansprach.

Und Eric hat wörtlich gesagt:
You should contact devrel -- They should be able to help. It's hard to speculate without seeing exactly what's going on. Our Devrel & Apps guys could analyze the code and find the issue, I'm sure. It could be a path where things are suboptimal -- Not sure.

"Nicht aussagekräftig" klingt anders.

[Xmas]

Die, die EDCFAA gesehen haben, waren davon alles andere als begeistert.
http://www.digit-life.com/articles2/video/r600-part4.html
Das steht in dem Artikel allerdings etwas anders.

Natürlich glaube ich auch, dass der G80 eine Menge Redundanz aufweist.
Aber wenn ATI das bis ins Extreme getrieben hat, sind nicht wenige dieser Transistoren gar nicht unbedingt im Einsatz.
Sollten sie aber trotzdem mit dem Taktisgnal versorgt werden (müssen?), ershließt sich gleich eine neue Quelle für die extrem hohen Verbrauchswerte.
Ich denke eher, dass sich durch erhöhte Granularität der Redundanz die Gesamtmenge ungenutzter Schaltungen senken lässt.

Also doch?
Also doch was?

[robbitop]

Genau genommen sind wir unabhängig voneinander darauf gekommen. Sein Posting hier im Forum dazu habe ich gar nicht gesehen bis ich ihn auf diesen Umstand ansprach.


Ich hoffe, du hast diese Vermutung in der PCGH nicht als Fakt hingestellt. :) (ich habe leider noch kein Exemplar diesen Monat)

[Gast]

Ich hoffe, du hast diese Vermutung in der PCGH nicht als Fakt hingestellt. :) (ich habe leider noch kein Exemplar diesen Monat)
Natürlich schreibe ich nichts, was man eine Unterstellung nennen könnte. Lediglich Folgerungen aus unseren Messungen. In diesem Fall "Offenbar ist die AA-Kompression nicht aktiv...". Und genau das ist der Schluss, der unseren Messungen zufolge naheliegt.

Ob das nun ein Hardware-Defekt ist oder per Software, möglicherweise applikationsspezifisch, behoben werden kann, weiß ich nicht.

[Gast]

Langsam geht die 2900XT rivhtig ab

1920 x 1200 Xbit lab mit Cat 7,5 (einige Beispielbenches)

BattleField 2142
2900 XT - 74.5
8800GTS - 51.4

Call Of Juarez
2900 XT -36.9
8800GTS -29.2

FarCry Pier
2900 XT - 123.6
8800GTS- 83.5

FarCry Research
2900 XT - 161
8800GTS -102.5

FarCryHDR Research
2900 XT -83.9
8800GTS-78

Fear Extraction Point
2900 XT -42
8800GTS-36

Prey:
2900 XT - 51.6
8800GTS- 43.9

SplinterCell:
2900 XT - 54.6
8800GTS-46

Oblivion indoor:
2900 XT -71.1
8800GTS -66.3

Oblivion Outdoor:
2900 XT -50.1
8800GTS -47.1

X3 Reunion:
2900 XT -80.4
8800GTS -69.6

Company of Heroes
2900 XT -75.2
8800GTS-53.7

toll, ohne AA und vor allem AF war die radeon schon immer stark, mit AA/AF liegt sie aber maximal gleich auf mit der 8800GTS.

[seahawk]

Nix ohne AA+AF, mit 4xAA + 16xAF

http://www.xbitlabs.com/articles/video/display/xfx-gf8800ultra-extreme_7.html#sect2

Oft killt sie sogar die Ultra.

[Gast]

toll, ohne AA und vor allem AF war die radeon schon immer stark, mit AA/AF liegt sie aber maximal gleich auf mit der 8800GTS.

Traditionell waren da die GeForces immer stärker als die Radeons. Mit AA/AF gingen die GeForces alle ziemlich unter.

Aber ATi wird das Blatt schon wieder wenden! Wenn man Jahrelang geführt hat, dann darf auch mal ein kleiner Ausrutscher passieren.

[HOT]

Nix ohne AA+AF, mit 4xAA + 16xAF

http://www.xbitlabs.com/articles/video/display/xfx-gf8800ultra-extreme_7.html#sect2

Oft killt sie sogar die Ultra.
Sogar Transparenz MSAA ist an. Aber die Benches sind wirklich sehr unausgewogen. Wo die 2900 sonst sehr stark war ist sie jetzt plötzlich sehr langsam. Mal sehen was da treibertechnisch so noch kommt... es macht auf jeden Fall Hoffnung auf mehr.

[Coda]

Also doch was?
Naja, es wurde doch immer von einigen angezweifelt, dass DooM³ wegen Stencildingen auf nVIDIA schneller läuft.

[LovesuckZ]

Aber ATi wird das Blatt schon wieder wenden! Wenn man Jahrelang geführt hat, dann darf auch mal ein kleiner Ausrutscher passieren.

Seit dem NV40/r420 haben sie nicht mehr geführt. Ihr Marktanteil sowie die Umsätze und der Gewinn schrumpfen von Jahr zu Jahr.

[laser114]

Seit dem NV40/r420 haben sie nicht mehr geführt. Ihr Marktanteil sowie die Umsätze und der Gewinn schrumpfen von Jahr zu Jahr.

Zwischen R580/G71 und dem G80 sah ich ATI klar vorne.

[Coda]

Der Markt sah das leider anders.

[LovesuckZ]

Zwischen R580/G71 und dem G80 sah ich ATI klar vorne.

Schonmal auf dem Notebooksektor geschaut? ;)
Im High-End waren sie konkurrenzfähig, aber das reichte nicht, um die Marktanteile zu behalten.

[Sterem]

Seit dem NV40/r420 haben sie nicht mehr geführt. Ihr Marktanteil sowie die Umsätze und der Gewinn schrumpfen von Jahr zu Jahr.

Ja auch nur weil noobs aufdenn PS 3.0 hype reingefallen sind.Es haben sich bestimm 80 % der Menschheit lieber eine 6800 anstat einer X800 gekauft nur wegen Ps 3-0.Hat leider nichts gebracht,der X800 User konnte noch lange länger flüssig Spielorn....

[reunion]

Ihr Marktanteil sowie die Umsätze und der Gewinn schrumpfen von Jahr zu Jahr.

Der Rekordumsatz in der Firmengeschichte von Ati wurde kurz vor dem Übernahme erzielt. :rolleyes:

Schonmal auf dem Notebooksektor geschaut? ;)


Schonmal bemerkt, dass dafür ein völlig andere Ereignis maßgeblich ist? Bis zur Übernahme von AMD hielt ATi stets >2/3 des Notebook stand-alone Marktes. Tw. sogar über 90%.

[LovesuckZ]

Schonmal bemerkt, dass dafür ein völlig andere Ereignis maßgeblich ist? Bis zur Übernahme von AMD hielt ATi stets >2/3 des Notebook stand-alone Marktes. Tw. sogar über 90%.

Welches Ergebnis außer die stromsparende Hardware sei denn für das superbe Abschneiden von nVidia verantwörtlich?

/edit: Ich sehe gerade, dass ATI's Umsatz nicht gesunken ist. Da habe ich mich geirrt.

[Mancko]

Welches Ergebnis außer die stromsparende Hardware sei denn für das superbe Abschneiden von nVidia verantwörtlich?

Frag ich mich auch gerade. Bereits vor der Übernahme ging bei ATI die Kurve im Notebook Sektor stark abwärts.
Der G7x war für den Notebook Sektor die bessere GPU, weil das Teil genügsam beim Stromverbrauch war.
ATIs Design reichte zwar für den Desktop High End Markt aber der recht hohe Stromverbrauch hat sich gleichmal negativ auf die gesamte Produktpalette im Notebook-Sektor durchgeschlagen.
Dort wird nicht primär auf die BQ geschaut sondern auf die in Relation zum Stromverbrauch erbrachte Performance. Da lag Nvidia klar vorn.
G7x hat für Nvidia die Wende im Notebookbereich gebracht. Bereits zu NV4x Zeiten gab es erste Achtungserfolge für Nvidia.

Jetzt liegen sie deutlich vor ATI.

[Gast]

Leider konnte man mit der X800 nicht länger besser spielen wie mit den 6800er Karten, es gibt schon länger Spiele die SM 3.0 Hardware voraussetzen und mit einer X800 gar nicht erst starten ;).

[jay.gee]

......es gibt schon länger Spiele die SM 3.0 Hardware voraussetzen und mit einer X800 gar nicht erst starten ;).

Dann mal viel Spass bei diesen Spielen, mit der 6800er. ;)

[Gast]

Dann mal viel Spass bei diesen Spielen, mit der 6800er. ;)Kein Problem in kleinen Auflösungen mit niedrigen bis mittleren Details. Es gibt auch andere Einstellungen als alle Regler auf Anschlag rechts.

[DerKleineCrisu]

Ja auch nur weil noobs aufdenn PS 3.0 hype reingefallen sind.Es haben sich bestimm 80 % der Menschheit lieber eine 6800 anstat einer X800 gekauft nur wegen Ps 3-0.Hat leider nichts gebracht,der X800 User konnte noch lange länger flüssig Spielorn....

naja ATI mit ihrer x1xxxx serie sind nicht besser. die halten sich ja auch nicht an die vorgaben sm 3.0 sondern " legen " die vorgabe so aus wie sie es wollten ( siehe aa+hdr was gem vorgabe nicht gehen sollte ).


@jay|gee viel spass mit einer x800 wenn das spiel nur mit einer graka geht die sm 3.0 hat :wink: .

[Benedikt]

naja ATI mit ihrer x1xxxx serie sind nicht besser. die halten sich ja auch nicht an die vorgaben sm 3.0 sondern " legen " die vorgabe so aus wie sie es wollten ( siehe aa+hdr was gem vorgabe nicht gehen sollte ).


@jay|gee viel spass mit einer x800 wenn das spiel nur mit einer graka geht die sm 3.0 hat :wink: .
Was da, in der Leistungsklasse "flüssig spielbar auf 6800" wäre?

[Gast]

Leider konnte man mit der X800 nicht länger besser spielen wie mit den 6800er Karten, es gibt schon länger Spiele die SM 3.0 Hardware voraussetzen und mit einer X800 gar nicht erst starten ;).

Hmm Splinter Cell ist nichtmehr das was es mal war......

[Xmas]

naja ATI mit ihrer x1xxxx serie sind nicht besser. die halten sich ja auch nicht an die vorgaben sm 3.0 sondern " legen " die vorgabe so aus wie sie es wollten ( siehe aa+hdr was gem vorgabe nicht gehen sollte ).
Welche "Vorgabe" soll denn das sein nach der AA+HDR nicht gehen sollte?

[HOT]

Leider konnte man mit der X800 nicht länger besser spielen wie mit den 6800er Karten, es gibt schon länger Spiele die SM 3.0 Hardware voraussetzen und mit einer X800 gar nicht erst starten ;).
Tolle Konsolenumsetzungen... davon sind aber die allermeisten auf einer 6xxx nicht mehr flüssig spielbar.
Features vs. Leistung spielt im Prinzip keine Rolle. Kommt halt auf die Vorlieben an. Wenn man jetzt meint, man müsste diese Standard-Konsolengames zocken ist die 6800 sicher die bessere Wahl gewesen... aber wissen kann man weder das eine noch das andere vorher.

[Gast]

naja ATI mit ihrer x1xxxx serie sind nicht besser. die halten sich ja auch nicht an die vorgaben sm 3.0 sondern " legen " die vorgabe so aus wie sie es wollten ( siehe aa+hdr was gem vorgabe nicht gehen sollte ). Wie Xmas schon andeutete gibt es keine Vorgabe, die die Verwendung von MSAA bei FP-Rendertargets "verbietet". Das ändert aber nichts daran, dass ATI trotzdem etwas "kreativ" beim Auslegen der SM3-Specs war, aber das ist eine andere Sache, die in früheren Threads schon zur Genüge diskutiert wurde.

[Gast]

Dann mal viel Spass bei diesen Spielen, mit der 6800er. ;)

ich hatte mit meiner 6800GT sehr viel spaß mit splinter cell CT und musste nicht ein halbes jahr auf einen patch warten, der mir dann noch nichtmal HDR ermöglicht.

auch leistungsmäßig war ATI nur bei der top-karte besser, X800XT war merklich schneller als die 6800Ultra, in der klasse 6800GT vs. X800Pro gab es leichte vorteile für NV. im mainstream hatte man gegen eine 6600GT überhaupt keine chance und hatte auf AGP ewig garnichts zu bieten.

wenn man die reihe NV4x gegen R(V)4xx vergleicht hatte ATI genau in einem preissegment die schnellere karte, in allen anderen war man maximal gleich schnell oder merklich unterlegen und hatte auch abseits der geschwindigkeit nachteile wie ua. das fehlende SM3 oder auch kein videoprozessor, der immerhin einer alten 6600 schon H.264-beschleunigung erlaubt.

[Gast]

die halten sich ja auch nicht an die vorgaben sm 3.0 sondern " legen " die vorgabe so aus wie sie es wollten ( siehe aa+hdr was gem vorgabe nicht gehen sollte ).


wo halten sie sich da nicht an die vorgaben? die R5xx-reihe kann MSAA auf FP16-rendertargets anwenden. überhaupt ist das garkeine vorgabe für SM3-kompatibilität, dennoch beherrschen die karten es einwandfrei.

FP16-filterung wird nicht angeboten, ist aber für SM3 auch nur optional vorgesehen.

das einzige wo man sich auf kreative weise die spezifikation zurechtgebogen hat, ist beim VTF, den man aufgrund einer spezifikationslücke nicht erfüllt hat.

[Grestorn]

FP16-filterung wird nicht angeboten, ist aber für SM3 auch nur optional vorgesehen.

das einzige wo man sich auf kreative weise die spezifikation zurechtgebogen hat, ist beim VTF, den man aufgrund einer spezifikationslücke nicht erfüllt hat.

FP16 Filterung war nie optional in DX9.0c/SM3

[Neomi]

FP16 Filterung war nie optional in DX9.0c/SM3

In DX 9.0c (das ist nur die API) ist sogar SM1 optional. Mit SM3 kommen natürlich diverse Anforderungen wie z.B. der Support von 4096er-Texturen und Geometry-Instancing, an FP16-Filterung kann ich mich jetzt aber nicht erinnern. Hast du da eine offizielle Quelle, die was anderes behauptet?

[Demi@gast]

FP16 Filterung ist nicht an SM3 gebunden.

[Grestorn]

Sorry, das hatte ich wohl falsch in Erinnerung.