PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Furmark, Throttling, Abhängigkeit von der GPU-Architektur (Split aus Antilles-Thread)


Hugo78
2011-03-01, 18:21:37
aber nur @ furmark und umbenannter exe


Also ...
AMD hat bei der HD4k in Software einen TDP Begrenzer eingeführt.
Bei der HD5k ist diese Drossel dann in Hardware verbaut worden, eine Drossel die Furmark ähnliche Lastzustände erkennt
und im Fall der Fälle, entsprechend ihrer Bestimmung reagiert.

Und der einzige Vorwurf den man NVidia hier machen kann ist,
dass sie solche Deppen waren und nicht auch bei der Einführung der GTX 400 Reihe diese Art Drossel verbauten. Bei der 500er ist das ja jetzt der Fall.

Denn ausser Furmark, was du hier nicht für die 4870 X2 gelten lassen möchtest, gibt es kein Spiel in dem die 480 ihre TDP so extrem weit übersteigt.

5-10% war man sicherlich in Crysis @max drüber, aber allgemein gesehen ist die Angabe mit 250W schon ein passender Wert.

Beispiele:

249W
http://ht4u.net/reviews/2010/zotac_geforce_gtx_480_amp_limited_edition/index12.php

230W (BFBC2)
http://www.pcgameshardware.de/aid,798165/Geforce-GTX-580-im-Test-Die-bessere-Geforce-GTX-480/Grafikkarte/Test/?page=2

257W (3DMark 03)
http://tpucdn.com/reviews/ASUS/GeForce_GTX_560_Ti_Direct_Cu_II/images/power_peak.gif
http://www.techpowerup.com/reviews/ASUS/GeForce_GTX_560_Ti_Direct_Cu_II/26.html

Aber wenns von Nvidia kommt, ist es grundsätzlich böse und überhaupt AMD hat jetzt schon ne Wolke gleich neben Mutter Theresa sicher,
fehlt nur noch die Seeligsprechung zu Lebzeiten, ich weiß ... :devil:

Hugo78
2011-03-02, 20:23:31
Bei der Masse der Leute steht TDP ebend nicht für irgendeinen, temorär, praktischen Mittelwert (a la ACP), sondern für die maximale Verlustleistung und hier ist es egal, aus welchen praktischen Überlegungen heraus, AMD hier nur 286W angesetzt hatte, denn morgen kommt eine Anwendung die nicht nur 3,7 sondern im Mittel 4,8 der 5 Vec auslastet und schon ist die TDP jenseits der 350W.

Und btw, die HD4k Reihe wird noch von vielen benutzt, genauso wie ich immernoch meine GTX 200er benutze.
Und 5Vec wird auch noch in der Masse (80% oder?!) der aktuellen HD6k verwendet, ausser Cayman.

Der Bezug ist also nicht auf eine 2 jahre alte Karte, sondern der auf eine immernoch aktuell im Laden kaufbare Architektur.

Lass doch mal morgen einen Open CL Progger Gott, den ultimativen Code schreiben, ein Videorender zb... ohne Limiter geht dann auch die 6870 durch die Decke,
genau wie sie es in Furmark gehen würde (wenns nicht den Limiter geben würde).

Hier Furmark als unfair oder "für Radeons nochmal unfairererererer" darzustellen ist doch recht mutig.

redfirediablo
2011-03-03, 16:08:57
Es gibt kein treiberthrottling mehr bei der 69XX Serie. Alles Hardwareseitig implementiert und damit nicht umgehbar.

Gipsel
2011-03-03, 17:59:48
Was soll der Kram mit dem Throttling hier schon wieder. Eine HD6900er throttelt auch in FurMark nicht bei Powertune ab +15%. Und vom Vergleich der Performancewerte von HD5800 und HD6900 (und anderer Indizien) throtteln auch die HD5800er bei Furmark im Normalfall nicht. Die relative Leistungsschwäche der HD5800er und HD6900er im Vergleich zu den (ungebremsten) HD4000er Karten kommt wahrscheinlich von einem nicht optimal balanciertem Workload von FurMark, der die Architekturänderungen (meiner Vermutung nach die L2-Cache-Anbindung) nicht angemessen berücksichtigt.

Captain Future
2011-03-04, 11:19:30
Was soll der Kram mit dem Throttling hier schon wieder. Eine HD6900er throttelt auch in FurMark nicht bei Powertune ab +15%. Und vom Vergleich der Performancewerte von HD5800 und HD6900 (und anderer Indizien) throtteln auch die HD5800er bei Furmark im Normalfall nicht. Die relative Leistungsschwäche der HD5800er und HD6900er im Vergleich zu den (ungebremsten) HD4000er Karten kommt wahrscheinlich von einem nicht optimal balanciertem Workload von FurMark, der die Architekturänderungen (meiner Vermutung nach die L2-Cache-Anbindung) nicht angemessen berücksichtigt.
Ich bezweifle das:
http://www.gpu-tech.org/showthread.php/13-Furmark-1.7.0-Scaling-with-different-core-and-memory-clocks

Allein schon der Unterschied zwischen Benchmarkmodus und Extreme Burning. Die ungedrosselte 4870 legt 43%, die 5870 satte 61% zu, wenn man von Extreme Burning zum Benchmark Modus wechselt.

Davor, als sich die Architekturen wesentlich stärker geändert haben, skalierte Furmark hingegen nahezu 1:1 mit der stiegenden Nummer von ALUS.

Dural
2011-03-04, 12:49:43
Klar wird gedrosselte, als damals massenhaft die 4850 in Furmark abgefackelt sind musste AMD reagieren und hat per Software die Karten runter gedrosselt und das dürfte bis heute noch der Fall sein, wieso sollte AMD das auch wider lockern wenn sie schon früher in Furmark Probleme hatten...

Am Anfang konnte man die Drosselung auch mit exe Umbenennung umgehen...

Gipsel
2011-03-04, 13:45:31
Ich bezweifle das:
http://www.gpu-tech.org/showthread.php/13-Furmark-1.7.0-Scaling-with-different-core-and-memory-clocksDas kenne ich. Soll Carsten doich mal Werte der definitiv ungethrottelten HD6950/70 dazuschreiben ;)
Allein schon der Unterschied zwischen Benchmarkmodus und Extreme Burning. Die ungedrosselte 4870 legt 43%, die 5870 satte 61% zu, wenn man von Extreme Burning zum Benchmark Modus wechselt.Und das soll mir was sagen? Paßt genauso gut dazu, daß der Workload von Furmark (und insbesondere der Burning Mode) für die HD5800er nicht optimal balanciert ist.
Davor, als sich die Architekturen wesentlich stärker geändert haben, skalierte Furmark hingegen nahezu 1:1 mit der stiegenden Nummer von ALUS.Nun, das kommt natürlich immer darauf an, ob der Test auf eine bestimmte Änderung sensitiv ist. Und wenn man die maximale Stromaufnahme einer GPU erreichen will, spielt das L2-Cache-Interface eine nicht zu unterschätzende Rolle (den Shader-Block bekommt man mit anderen Instruktionssequenzen als FurMark wärmer, da liegt aber die Gesamtstromaufnahme trotzdem niedriger, weil auch die TMUs und das Speicherinterface ausgelastet werden wollen). Und die Proportionen haben sich da mit der HD5800ern nunmal deutlich geändert.

Meiner Vermutung nach ist FurMark ziemlich perfekt auf das alte R600/RV670-Design ausgelegt (praktisch mit unified Texture-Caches). Schon der Übergang zum RV770 skalierte nicht mehr perfekt, sondern laut CarstenS' Zahlen nach Berücksichtigung von Takt und Einheitzahlen nur noch zu 77%. Das L2/L1-Bandbreitenverhältnis beträgt bei RV770 übrigens 80% (und die RV770-Organisation der TMUs ist prinzipiell etwas ineffizienter als R600/RV670).
Bei RV870 geht die Skalierung gegenüber RV670 auf 54% zurück. Allerdings liegt jetzt auch das L2/L1-Bandbreitenverhältnis bei nur noch 40%. Also ich erkenne da einen deutlichen Trend bzw. Flaschenhals.

Dazu kommt wie gesagt, daß die HD6970er definitiv nicht mehr throtteln, wenn man Powertune etwas anhebt. Außerdem ist das Throtteln z.B. mit dem Afterburner beobachtbar, übrigens auch bei einer HD5870 (hatte mal ein Screenshot davon gepostet). Bei Furmark tritt das aber bei normalen Einstellungen mit einer HD5870er nicht auf.

Gipsel
2011-03-04, 13:47:34
Klar wird gedrosselte, als damals massenhaft die 4850 in Furmark abgefackelt sind musste AMD reagieren und hat per Software die Karten runter gedrosselt und das dürfte bis heute noch der Fall sein, wieso sollte AMD das auch wider lockern wenn sie schon früher in Furmark Probleme hatten...

Am Anfang konnte man die Drosselung auch mit exe Umbenennung umgehen...Genau, bei HD4800ern. HD5800er aufwärts werden nicht mehr per Software gedrosselt. Hat AMD mehrfach gesagt und es spricht nichts dagegen, daß das auch stimmt.

Captain Future
2011-03-04, 17:04:57
Ok, dann schauen wir uns die Zahlen da doch mal genauer an.

- Zwischen X850 und X1800 passiert trotz der besseren Architektur pro Takt und Einheit quasi nix.
- Zwischen X1800 und X1950 sehe ich eine fast lineare skalierung mit der Anzahl der Pixelshader (x3 Shader, x2,66 pro Takt)

- Zwischen X1950 und HD2900 52% mehr Performance bei 52% mehr PS (wenn ich mal die Vektoreinheiten 64 zu 48 (x1,33) und den Takt (x1,14) rechne). Das spräche übrigens nicht gerade für eine ideale Optimierung auf die R600/RV670-Architektur.

- Zwischen HD2900 und HD3870 quasi keine Änderung, der halbierte interne Ringbus macht also offenbar auch nicht viel aus.

- Zwischen HD 4870 und 3870 87% plus (taktbereinigt nur 81%), bei 2,5x sovielen ALU/TMUs. Hier könnten wirklich die von dir angepsorchenen Probleme reinspielen - es könnte allerdings auch sein, dass beim RV770 die interpolatoren (32 für 40 TMUs) limitieren - dann kommt es wieder wesentlich besser hin, wenn man RV770 als 32 TMU CHip ansieht und annimmt, dass die Textureinheiten das "Problem" sind.

Schade, dass da keine 5770 mit bei ist, die auch 32 hat, sondern nur im Extreme burning mode. :(

Außerdem: WEnn/Falls die TMUs bzw. deren Cache der Flaschenhals sein sollten, müsste eine höhere Bandbreite das doch zum Teil wieder einfangen können, oder?


Zum Unterschied von Benchmark und Extreme Burning: Hast du dir das schonmal rein optisch angeguckt? Das ist einfach nur die Ansicht, wo am meisten vom Donut zu sehen ist. Ich habe es gerade mal ausprobiert: Die Fps entsprechen auf meinem PC (HD 2900 XT) auch denen, die beim Benchmarkmodus in derselben Donutstellung erreicht werden.

Gipsel
2011-03-04, 18:37:57
Ok, dann schauen wir uns die Zahlen da doch mal genauer an.
Wird zwar ziemlich OT, aber meinetwegen.
- Zwischen X850 und X1800 passiert trotz der besseren Architektur pro Takt und Einheit quasi nix.Ist ja bis auf DX9.0c und ein paar mehr Vertexprozessoren praktisch auch die gleiche Architektur ;)
- Zwischen X1800 und X1950 sehe ich eine fast lineare skalierung mit der Anzahl der Pixelshader (x3 Shader, x2,66 pro Takt)Ja, skaliert gut mit den Shadern, die TMUs limitieren aber schon minimal.
- Zwischen X1950 und HD2900 52% mehr Performance bei 52% mehr PS (wenn ich mal die Vektoreinheiten 64 zu 48 (x1,33) und den Takt (x1,14) rechne). Das spräche übrigens nicht gerade für eine ideale Optimierung auf die R600/RV670-Architektur.
Nun, die theoretische Rechenleistung geht sogar auf
(64 * 5) / (48 * 4) * 743 / 648 = 191%
hoch. Die 5er-VLIWs sind sogar je nach Code flexibler nutzbar als die Vec3+1-Pixel-Shadereinheiten des R580 (nur die Vertexshader waren 4+1), was die Steigerung der Breite im Allgemeinen locker kompensieren dürfte. Was sich aber nur entsprechend dem Takt verändert hat, ist die TMU-Leistung.
=> limitierte Skalierung
Allerdings ist es etwas mutig, die doch recht verschiedenen R580 und R600 so zu vergleichen.

Übrigens, wenn Du die These aufstellst, FurMark paßt eigentlich am besten zur R580-Architektur, dann ist das sogar noch eine Steigerung meines Arguments, daß der Workload nicht optimal für die HD5800er ist ;)
- Zwischen HD2900 und HD3870 quasi keine Änderung, der halbierte interne Ringbus macht also offenbar auch nicht viel aus.An der Anbindung der Caches hat sich ja auch nichts geändert ;)
- Zwischen HD 4870 und 3870 87% plus (taktbereinigt nur 81%), bei 2,5x sovielen ALU/TMUs. Hier könnten wirklich die von dir angepsorchenen Probleme reinspielen - es könnte allerdings auch sein, dass beim RV770 die interpolatoren (32 für 40 TMUs) limitieren - dann kommt es wieder wesentlich besser hin, wenn man RV770 als 32 TMU CHip ansieht und annimmt, dass die Textureinheiten das "Problem" sind.Ob die TMUs die Daten nur mit 80% der Geschwindigkeit bekommen oder es nur 80% der TMUs gibt, ist in diesem Zusammenhang fast egal ;)
Außerdem: WEnn/Falls die TMUs bzw. deren Cache der Flaschenhals sein sollten, müsste eine höhere Bandbreite das doch zum Teil wieder einfangen können, oder?Nicht wirklich. Eine HD4870 hat 384GB/s L2-Bandbreite. Ob jetzt 64 oder 100 GB/s Speicher dahinter hängen, spielt keine Rolle, falls die Bandbreite (und nicht die Größe) des L2 limitiert. Eine HD5870 steht übrigens auch nur bei 435GB/s L2-Bandbreite. Da ist es dann kein Wunder, warum die Skalierung nicht nur bei FurMark zur HD4870 meist kleiner als Faktor 2*Taktvorteil beträgt.
Zum Unterschied von Benchmark und Extreme Burning: Hast du dir das schonmal rein optisch angeguckt? Das ist einfach nur die Ansicht, wo am meisten vom Donut zu sehen ist. Ich habe es gerade mal ausprobiert: Die Fps entsprechen auf meinem PC (HD 2900 XT) auch denen, die beim Benchmarkmodus in derselben Donutstellung erreicht werden.Ja und? Sowas ändert natürlich auch das Verhältnis von Shader-/Tex-Instruktionen und vor allem auch die Verteilung der letzteren im Speicher (wichtig für die Cache-Hits).

PS:
Wenn Bedarf an einer weiteren Diskussion diesbezüglich besteht, kann ich das gerne auch in einen anderen Thread auslagern.

LovesuckZ
2011-03-04, 19:02:54
Furmark wird regelmäßig überarbeitet. Man kann sehr wohl davon ausgehen, dass für jede Architektur ein entsprechender Last-Code vorhanden ist.

Gipsel
2011-03-04, 20:39:54
Furmark wird regelmäßig überarbeitet. Man kann sehr wohl davon ausgehen, dass für jede Architektur ein entsprechender Last-Code vorhanden ist.
Du meinst also, daß jede GPU einen anderen Code ausführt? Also nv-Code != Radeon-Code, HD4000er-Code != HD5000er-Code oder sogar noch getrennt nach jedem Modell?

Das wäre wirklich notwendig, wenn man jede GPU an die Grenze bringen will. Allerdings will sich wohl kaum einer die Mühe machen, für jedes GPU-Modell einen eigenen Codepfad zu schreiben.
=> einige GPU-Modelle kommen eben nicht auf die maximale Auslastung, weil vorher irgendein Flaschenhals etwas zu eng wird

Wie gesagt ist es gut möglich, den Shadercore der Radeons wärmer zu bekommen als mit FurMark. Der stellt also keinesfalls das Optimum in diesem Sinne dar. Aber für maximalen Stromverbrauch muß nicht nur der beschäftigt sein, sondern auch TMUs, die L1-Caches, die L2-Caches (Lesen aus L2 kostet mehr Power als aus L1, aber bremst und verringert damit den Stromverbrauch, falls man zu viel daraus liest), ROPs mit den zugehörigen Caches und natürlich auch das Speicherinterface (hier gilt das Gleiche wie für L1/L2 Texture-Cache). Da die Bandbreiten und Cachegrößen für jedes Modell unterschiedlich sind, ist es sehr schwer, wirklich für jedes Modell optimal auf Verbrauchsmaximierung zu tunen. Dies findet meiner Meinung daher einfach nicht statt sondern man versucht es mit einem Kompromiß.

Coda
2011-03-04, 21:27:43
Ist ja bis auf DX9.0c und ein paar mehr Vertexprozessoren praktisch auch die gleiche Architektur ;)
Nö.

=Floi=
2011-03-04, 21:57:25
wie sieht es denn bei nv aus? sind da die caches besser oder schlechter bemessen und angebunden? (im hinblick auf gpgpu!)
ist das maximum dann auf karten von nv ausgelegt?! (weil es eben auch bessere tools dafür gibt um damit die auslastung zu testen?)

=Floi=
2011-03-04, 21:58:12
Nö.

deine billigen posts kannst du dir auch mal sparen. :P

Gipsel
2011-03-04, 22:50:07
Nö.
Das war ein wenig vor meiner Zeit, aber der einzige in diesem Zusammenhang wesentliche Unterschied in den Blockdiagrammen ist die Verlagerung von den TAUs aus den Pixelpipelines in ein separates Array vor die TMUs (die waren aber auch schon beim R420 entkoppelt). Aber wer weiß, inwieweit das überhaupt der Wahrheit entpricht. Denn Du willst doch bestimmt nicht auf den Ringbus hinaus, oder?

Hugo78
2011-03-04, 23:02:03
Nur mal so, ich seh mich hier nicht als "Thread-Starter".
Nur als Reagierender auf "redfirediablo's" plattes Bashing, was dann im Furmarkquark enden musste, dank weiterer AMD Fans die noch weniger Stil hatten als "redfirediablo".

Und der Split von Gispel zeigt das recht offen ... nun ja bitte. *lächerlich*

Coda
2011-03-04, 23:02:34
Da wurde mehr gedreht. R4xx hatte ja immer noch das Phasen-Konzept, und ich bin mir relativ sicher, dass es da auch keinen Thread-Arbiter gab unso. So einfach geschenkt hat man das sehr schnelle dynamic branching nicht bekommen. Außerdem kann R5xx ja auch beliebig lange Programme.

Also von gleicher Architektur zu reden halte ich für etwas übertrieben ;)

Gipsel
2011-03-04, 23:02:59
wie sieht es denn bei nv aus? sind da die caches besser oder schlechter bemessen und angebunden? (im hinblick auf gpgpu!)
ist das maximum dann auf karten von nv ausgelegt?! (weil es eben auch bessere tools dafür gibt um damit die auslastung zu testen?)
Das ist ziemlich schwer zu vergleichen, insbesondere auch bei GPGPU. Da besitzen nv-GPUs seit Fermi ja zwei verschiedene L1-Caches. Einen "dual use fähigen" GP-L1 (wahlweise 16/48 oder 48/16 kB partitioniert für L1/local memory) und eben den "normalen" Tex-L1. Und selbst die Texture-L1 lassen sich schwer vergleichen, da sie deutlich anders arbeiten.

Bei nv stehen im L1 noch komprimierte Texturen. Die werden erst beim Lesen durch die TMUs on-the-fly entpackt. Bei Radeons passiert das Entpacken schon beim Laden vom L2 in den L1. Die nominelle Bandbreite des L2 ist demzufolge bei Radeons zum Teil deutlich höher (eine HD4870 hat mehr L2->L1 Bandbreite als eine GTX580), allerdings muß sie das auch sein, weil wie gesagt da dort schon unkomprimierte Texturen drübergeschoben werden.

Allgemein kann man sagen, daß nv-GPUs spätestens seit Fermi das deutlich aufwendigere Cache-Design haben. Und umsonst macht nvidia das bestimmt nicht.

Gipsel
2011-03-04, 23:08:26
Da wurde mehr gedreht. R4xx hatte ja immer noch das Phasen-Konzept, und ich bin mir relativ sicher, dass es da auch keinen Thread-Arbiter gab unso. So einfach geschenkt hat man das sehr schnelle dynamic branching nicht bekommen. Außerdem kann R5xx ja auch beliebig lange Programme.

Also von gleicher Architektur zu reden halte ich für etwas übertrieben ;)
Okay, das Phasen-Konzept sagt mir jetzt zwar nichts, aber da glaube ich Dir einfach mal. War wie gesagt vor meiner Zeit.

Wichtig in diesem Zusammenhang wäre mir das Shader/TMU-Verhältnis und die Anbindung der TMUs. Hat sich da was getan? Ich glaube eher nichts Wesentliches, oder?

Coda
2011-03-04, 23:46:45
Weiß ich nicht genau. Möglicherweise waren bei R4xx die TMUs fest an die Pixelprozessoren gebunden. Bei R5xx und R6xx ist das ja nicht so.

Gipsel
2011-03-05, 00:37:28
Weiß ich nicht genau. Möglicherweise waren bei R4xx die TMUs fest an die Pixelprozessoren gebunden. Bei R5xx und R6xx ist das ja nicht so.
Na, wie ich sagte, waren die TMUs auch bei R420 zumindest schon entkoppelt (afaik anders als bei nv zu der Zeit).

Coda
2011-03-05, 01:26:49
R420 war doch nur ein aufgeblasener R300. War das da auch schon der Fall?

LovesuckZ
2011-03-05, 02:14:09
Du meinst also, daß jede GPU einen anderen Code ausführt? Also nv-Code != Radeon-Code, HD4000er-Code != HD5000er-Code oder sogar noch getrennt nach jedem Modell?

Das wäre wirklich notwendig, wenn man jede GPU an die Grenze bringen will. Allerdings will sich wohl kaum einer die Mühe machen, für jedes GPU-Modell einen eigenen Codepfad zu schreiben.
=> einige GPU-Modelle kommen eben nicht auf die maximale Auslastung, weil vorher irgendein Flaschenhals etwas zu eng wird

Natürlich. Was soll daran aufwendig sein? Neue Architekturen kommen alle 1 1/2 - 2 Jahre raus.
Und das man nicht an die maximale Auslastung kommt ist doch logisch, wenn vorher per Software und/oder Hardware gebremst wird. :freak:

Gipsel
2011-03-05, 04:46:57
@LS:
Na so lange Du das nicht machen mußt, hast Du gut reden. :rolleyes:

Hast Du irgendeinen Hinweis darauf, daß Furmark für jede GPU angepaßten Code ausführt? Ich nämlich nicht (würde auch irgendwie die Benchmarkfunktion ad absurdum führen :rolleyes:). Also put up or shut up!

Gipsel
2011-03-05, 05:33:28
R420 war doch nur ein aufgeblasener R300. War das da auch schon der Fall?Zwar unter Vorbehalt (mit dem alten Kram kenne ich mich nicht aus), aber ja. Allerdings reden wir gerade vielleicht etwas aneinander vorbei. So eine TMU war schon einer Pixelpipeline zugeordnet (wie heute 4 TMUs einem SIMD). Mit entkoppelt meine ich, daß die Tex-Instruktionen im Prinzip unabhängig (d.h. parallel) von dem anderen Shader-Kram ausgeführt werden können. Sie sind also nicht mehr fest in die Pipeline eingebunden. Threading und so gab's ja schon.

Ailuros
2011-03-05, 10:18:52
Wenn mich mein Gedaechtnis nicht betruegt waren TMUs schon seit R300 von den ALUs entkoppelt.

Zum Thema hier:

http://forum.beyond3d.com/showpost.php?p=1496891&postcount=7536

I don't know what is actually happening, but a reason that you may app detect for something like this could be because the driver may need to poll the current monitoring / regualtor devices for activity, which can chew up CPU cycles; you certainly don't want to do this for all apps. The solution we implemented on Evergreen feeds directly into the microcontroller we have on the GPU, taking away any potential driver overhead and making the solution truly generic.

Und ich weiss bei bestem Willen nicht warum diese unsinnige Trottel-Throttelei so viel aufsehen generiert hat wenn es mir um etwas ganz anderes im originalen Thread ging, naehmlich wenn ein IHV X fuer 2*8pin auslegt dann heisst es nicht dass sie ein 300W TDP Ziel oder umgekehrt und nein so etwas entscheidet man auch nicht in der letzten Minute:

http://forum.beyond3d.com/showpost.php?p=1475980&postcount=97

Target TDP's is one of the design criteria when you build a chip because you have eventual product targets for that chip. When the chip comes back and you find out how far or close you are to the pre-silicon targets you make choices on what to do for the products, which may involve scaling back in performance. Given all the Fermi based products out there, I don't see any that are not operating in the TDP product ranges you are likely to plan for such products.

Coda
2011-03-05, 15:20:20
Zwar unter Vorbehalt (mit dem alten Kram kenne ich mich nicht aus), aber ja. Allerdings reden wir gerade vielleicht etwas aneinander vorbei. So eine TMU war schon einer Pixelpipeline zugeordnet (wie heute 4 TMUs einem SIMD). Mit entkoppelt meine ich, daß die Tex-Instruktionen im Prinzip unabhängig (d.h. parallel) von dem anderen Shader-Kram ausgeführt werden können. Sie sind also nicht mehr fest in die Pipeline eingebunden. Threading und so gab's ja schon.
Dann liegst du falsch. Bei R300 und R4xx wurde eben nicht mit Threading gearbeitet, sondern es wurden explizit in Phasen Bündel von unabhängig auszuführenden ALU- und Tex-Instructions festgelegt. Wenn dann beides fertig war wurde die nächste Phase ausgeführt.

Das ganze lief wohl immer pro Quad-ALU und pro Quad-TMU. Und deshalb gab's auch kein dynamisches Branching, weil das eben im Vorfeld vom Compiler festgelegt wurde.

Gipsel
2011-03-05, 16:24:36
Dann kam das Threading eben erst mit den R500ern. Aber aus Deiner Beschreibung kann man ja auch schon herauslesen, daß die Tex-Anweisungen in einer Phase parallel ohne Interferenz mit den ALU-Instruktionen abliefen.

Captain Future
2011-03-05, 16:49:12
Ja und?
Und? Ganz einfach: Wenn die Fps gleich sind, wieso dann so ein Unterschied in der Skalierung zwischen Benchmark und Extrem Burning?

Coda
2011-03-05, 16:59:01
Dann kam das Threading eben erst mit den R500ern. Aber aus Deiner Beschreibung kann man ja auch schon herauslesen, daß die Tex-Anweisungen in einer Phase parallel ohne Interferenz mit den ALU-Instruktionen abliefen.
Ich wollte dir nur erläutern, warum es ganz und gar nicht die gleiche Architektur ist.

PCGH_Carsten
2011-03-05, 21:43:36
Ich bin mal so frei und werfe ein paar Fragmente in den Raum:

• Die Xx00-Serie hatte noch ziemlich fest an die ALUs gekoppelte TMUs, die blockierten sich aber nicht gegenseitig wie bei den grünen Jungs.
• Die X1K-Serie hatte m.W. schon einen separaten TMU-Block, ähnlich den HD2k-3k.
• Die HD2K-Serie hatte ~180 GB/s Cache-Bandwidth (genauer definiert war die Angabe nicht), vermutlich dürfte das, taktangepasst, bei den 3000ern ähnlich sein.
• Die TMUs der HD2k/3k konnten neben den gefilterten auch einen ungefiltern Wert liefern. Ob das für den Furmark von Belang ist, weiß ich nicht.
• Was ich damals bei der Furmark-Skalierung auf jeden Fall nicht bedacht habe, ist die Tatsache, dass ab HD5k die Interpolation in den Shadern gemacht werden muss. So wie „anisotropic fur rendering” klingt, könnte da schon einiges interpoliert werden. Ist dass der Fall, limitieren die 32 Interpolatoren die HD 4800 mit Sicherheit.

Coda
2011-03-06, 15:32:24
• Die Xx00-Serie hatte noch ziemlich fest an die ALUs gekoppelte TMUs, die blockierten sich aber nicht gegenseitig wie bei den grünen Jungs.
Du meinst, dass die TMUs die ALUs nicht gestalled haben. Gegenseitig kamen sich die TMUs bei keinem Chip in die Quere.

fondness
2011-03-06, 16:00:27
Du meinst, dass die TMUs die ALUs nicht gestalled haben. Gegenseitig kamen sich die TMUs bei keinem Chip in die Quere.

Ist das nicht die zugrunde liegende Definition für "entkoppelte TMUs"? AFAIK sind die TMUs bei ATi mindestens seit R300, ich glaube sogar schon seit R200 entkoppelt. NV ging im Gegesatz dazu den Rampage-Weg. Was Carsten beschreibt ist dann die Darstellung im Blockdiagramm, was ich allerdings eher als Marketing bezeichnen würde.

Coda
2011-03-06, 16:31:47
Man darf da nicht mit der Nomenklatur durcheinanderkommen. Es gibt eine Entkopplung der TMU-Fetches von der ALU-Pipeline und eine Entkopplung vom SIMD-Cluster.

Letzteres hatten nur R5xx und R6xx. Die neuen GPUs haben die TMUs alle wieder in die ALU-Blöcke integriert.

Gipsel
2011-03-06, 17:16:27
Und? Ganz einfach: Wenn die Fps gleich sind, wieso dann so ein Unterschied in der Skalierung zwischen Benchmark und Extrem Burning?
Weil die GPU-Last eine andere ist. Es werden einfach andere Bereiche der GPU gefordert.

Den Effekt hast Du auch in Spielen. Eine Szene kann hauptsächlich vom Setup limitiert sein, eine andere pixelshaderlimitiert und wieder eine andere dann füllratenlimitiert. In jeder dieser Szenen würdest Du dann eine andere Skalierung sehen. Und ja, +-20% kann auch schon allein vom Blickwinkel auf eine Szene verursacht werden.

Gipsel
2011-03-06, 17:32:51
• Die HD2K-Serie hatte ~180 GB/s Cache-Bandwidth (genauer definiert war die Angabe nicht), vermutlich dürfte das, taktangepasst, bei den 3000ern ähnlich sein.
Die HD2k/HD3k hatten sehr sicher 16 Byte/Takt und TMU Bandbreite, also 256 Byte pro Takt für die Top-Modelle.

Der Unterschied zu den späteren Modellem besteht in der Organisation der TMUs und damit auch der Caches. Bei R600/RV670 waren die ja vollkommen eigenständig, ab RV770 sind ja 4 TMUs immer fest an einen SIMD gekoppelt. Neben der zwar etwas ineffizienteren aber dafür skalierbaren Organisation erzeugt man damit jetzt einen zusätzlichen Flaschenhals zwischen den L1 Caches (in jedem SIMD) und dem unified L2 Cache, der bei der R600-Organisation so nicht bestanden hat. Und diesen hat man mit Cypress (und afaik auch mit Cayman) nicht geweitet. Die Bandbreite beträgt bei Cypress immer noch die gleichen 512 Byte pro Takt, die auch schon eine HD4800 zur Verfügung hatte.
=> Böser Flaschenhals, wenn man darauf empfindlich ist (und das sollte man, wenn man maximalen Stromverbrauch aus einer GPU quetschen will)

Achja Carsten, irgendeine Chance, daß Du Deine Zahlen auf gpu-tech mit ein paar Werten einer HD6970 (mit angehobenem Powertune für garantierte Throttle-Freiheit) updatest? Ich habe zwar schon mal Zahlen aus anderer Quelle gesehen (die wie angedeutet zu meiner Argumentation passen), aber ich bin mir der Vergleichbarkeit nicht sicher.