Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD/ATI - RadeonPro schaltet Mikroruckler aus
w0mbat
2012-10-27, 04:02:57
http://www.tomshardware.de/Crossfire-SLI-Mikroruckler-Radeon-Pro,news-248333.html
Was sagt ihr dazu? Mit dem neuen RadeonPro (http://www.radeonpro.info) scheint CrossFire, laut THW, einen besseren Frameverlauf als SLI zu haben :biggrin:
boxleitnerb
2012-10-27, 06:24:55
Das sieht nach einem Framelimiter aus mit den entsprechenden Vor- und Nachteilen. Ist also nichts wirklich Neues und auch bei Nvidia möglich.
M4xw0lf
2012-10-27, 10:27:34
Es ist (unter anderem) ein Framelimiter und außerdem schon seit Monaten zu haben ^^
Schaffe89
2012-10-27, 11:07:47
TRotzdem wird noch überall ion den Threads geschrieben, dass µruckler mit AMD GRafikkarten nicht gezähmt werden könnten, insofern danke für die News.
y33H@
2012-10-27, 11:22:39
Ein Framelimiter ist halt - egal ob AMD oder Nvidia - nur eine Hilfslösung, behebt aber nicht das Ursprungsproblem.
TobiWahnKenobi
2012-10-27, 13:26:52
Das Ergebnis ist wirklich geradezu frappierend, so dass wir die Ergebnisse unseres Tests gern noch einmal auch an dieser Stelle in einem kleinen Auszug wiederholen. Betrachtet man die Frameraten und die von uns gemessenen Zeiten, die jeweils 1 Frame für die Erstellung benötigt, sieht sogar die adaptive VSync von Nvidia reichlich alt aus:
es sind auch unterschiedliche baustellen.. adaptiver sync, framelimiter..
http://www.abload.de/img/unbenanntydrn0.png
btw,
vorsätzlich limitiert habe ich noch nie.. zumindest nicht seit 120Hz panel + GTX690.
adaptiven sync finde ich hingegen gut - völligST unabhängig von MR.
eigentlich ist in verbindung mit nem limiter der adaptive sync überflüssig - da kann man sync auch gleich abschalten.
(..)
mfg
tobi
Ein Framelimiter ist halt - egal ob AMD oder Nvidia - nur eine Hilfslösung, behebt aber nicht das Ursprungsproblem.
Das kommt drauf an was du als Ursprungsproblem ansiehst. Die fehlende Kontrolle des Abstands zwischen den beiden GPUs behebt ein Framelimiter. Man könnte es natürlich auch durch eine Regelung statt einer Steuerung implementieren, aber etwas fundamental anderes wäre das auch nicht.
adaptiven sync finde ich hingegen gut - völligST unabhängig von MR.
eigentlich ist in verbindung mit nem limiter der adaptive sync überflüssig - da kann man sync auch gleich abschalten.ST?
Obwohl ich den Sinn im Adaptiven VSync nicht sehe (ich will auch/gerade bei geringen Frameraten kein Tearing), ist ein Frameratelimiter kein Ersatz für VSync. Kannst bei fixen 60fps (120fps oder whatever) einen konstanten Riss im Bild haben.
Zu RadeonPro: "DFC" ist kein *reiner* Framelimiter. Ich denke so bisschen wie in tb's Tool (sofern ich mich erinner, ist schon eine Zeit her) werden die Ausgabetimings berücksichtigt, damit Mikroruckler eliminiert werden.
"DVC" ist adaptives VSync:This feature controls how vertical synchronization is applied at rendering time, automatically turning it off when frame rate is below monitor's refresh rate to reduce stuttering and turning it on when framerate is above or equal to monitor's refresh rateQuellle (http://forums.guru3d.com/showpost.php?p=4389537&postcount=4871)
(del676)
2012-10-27, 17:45:08
Ich hab seit Monaten keine Mikroruckler mehr, dank MSI Afterburner. FPS Limiter auf 60fps rein, VSYNC ein, fertig.
aufkrawall
2012-10-27, 17:49:25
Man muss doch einfach nur im GPU-Limit genug fps für ein angenehmes Limit schaffen.
AFR ist nicht ideal, aber die Rucklerproblematik wird überbewertet.
Blaire
2012-10-27, 17:53:45
Man muss doch einfach nur im GPU-Limit genug fps für ein angenehmes Limit schaffen.
AFR ist nicht ideal, aber die Rucklerproblematik wird überbewertet.
Jo aber du kennst nur SLI :) Crossfire ist gefühlt wieder ganz anders, deutlich mehr Lag und ohne offene Profile ist das ganze eh fürn ...
Neben den Mikrorucklern finde die Lag-Problematik bei AFR ebenfalls... problematisch xD Dazu noch mehr Lag vom VSync muss nicht sein.
Okay, ich kenne es nicht aus eigener MGPU-Erfahrung und habe zu allem hin einen lahmen Monitor, insofern halt ich diesbezüglich mal die Klappe^^
aufkrawall
2012-10-27, 18:02:17
Neben den Mikrorucklern finde die Lag-Problematik bei AFR ebenfalls... problematisch xD Dazu noch mehr Lag vom VSync muss nicht sein.
Ist bei 2-Way mit SLI völlig unproblematisch.
Sachen wie UT, CSS oder TF2 gehen problemlos.
Ein fps-Limit verringert ja eh nochmal den Input-Lag und bei Nvidia kannst du über den Treiber auch die prerendered fps bei jedem Spiel begrenzen.
Okay, ich kenne es nicht aus eigener MGPU-Erfahrung und habe zu allem hin einen lahmen Monitor, insofern halt ich diesbezüglich mal die Klappe^^
;) :biggrin:
@Blaire: Crossfire kenn ich nicht, kann ich nicht beurteilen.
Keine vernünftig managebaren Custom Profile sind allerdings wirklich ein ziemlicher Nachteil.
Blaire
2012-10-27, 18:04:10
Ich hab seit Monaten keine Mikroruckler mehr, dank MSI Afterburner. FPS Limiter auf 60fps rein, VSYNC ein, fertig.
Glaub ich, dann muss aber auch das Profil mitspielen und auch bei NV können diese auch die Steuerung und die gefühlten FPS beeinflussen. Adaptives Vsync fand ich bei Diablo III ganz gut , ansonsten lass ich es meist aus, da der Lag spürbar ansteigt, gerade bei 4 GPUs.
Tesseract
2012-10-27, 19:21:33
Obwohl ich den Sinn im Adaptiven VSync nicht sehe (ich will auch/gerade bei geringen Frameraten kein Tearing)
wenn die FPS nicht reichen hat man immer ein problem. mit adaptivem vsync hat man halt die wahl ob man framevervielfachung oder tearing haben will - ohne die funktion waren es immer framevervielfachungen.
uweskw
2012-10-27, 19:29:45
Kaum gibts mal ne positive Meldung über AMD, schon kommen die NV-Boys angesprungen um es zu relativieren. Kommt bei positiven NV Meldungen kaum vor. Wo hat NV nur all die Hardcore-Fans her?
aufkrawall
2012-10-27, 19:30:21
Ein Vorteil bei adaptiv ist, dass man so quasi DB Vsync erzwingen kann, um den Input Lag noch etwas zu reduzieren.
Bringt bei manchen Spielen ein bisschen, bei anderen gar nichts.
Ailuros
2012-10-27, 20:56:15
Kaum gibts mal ne positive Meldung über AMD, schon kommen die NV-Boys angesprungen um es zu relativieren. Kommt bei positiven NV Meldungen kaum vor. Wo hat NV nur all die Hardcore-Fans her?
Jegliche Relativierung koennte sogar erwuenscht sein um die jeweilige Schwaechen bzw. Staerken der einen oder anderen Loesung zu definieren. Wenn Du etwas nutzvolleres und sachliches zum Thema beizutragen hast als das obrige eher ueberfluessige, ist es natuerlich mehr als willkommen.
Man muss doch einfach nur im GPU-Limit genug fps für ein angenehmes Limit schaffen.
AFR ist nicht ideal, aber die Rucklerproblematik wird überbewertet.
Je nach Perspektive wird es auch unterwertet. So bald beide IHVs durch den wachsenden Herstellungsprozess-Stress keinen anderen Ausweg mehr finden koennen werden sie an eine hw-basierende echte mGPU Loesung denken muessen (ueberhaupt fuer professionelle Maerkte) und dann erzaehlen uns die jeweiligen Marketing-/PR-Abteilungen was fuer ein bekloppter sw hack AFR wirklich war.
aufkrawall
2012-10-27, 21:04:16
Natürlich wär eine mGPU-Lösung toll, die auch ohne Limit die Frames regelmäßig rausgibt und es keine Probleme mehr mit gesonderten Profilen gäbe.
Was für Vorraussetzungen gegenüber jetzt müssen denn erfüllt werden, dass das ginge?
Blaire
2012-10-27, 21:25:17
Je nach Perspektive wird es auch unterwertet. So bald beide IHVs durch den wachsenden Herstellungsprozess-Stress keinen anderen Ausweg mehr finden koennen werden sie an eine hw-basierende echte mGPU Loesung denken muessen (ueberhaupt fuer professionelle Maerkte) und dann erzaehlen uns die jeweiligen Marketing-/PR-Abteilungen was fuer ein bekloppter sw hack AFR wirklich war.
Irgendwann wird das sicher kommen, aber ich glaube nicht zeitnah.
Was mich an der ganzen MR-Geschichte stört, das so ziemlich alles darunter fällt, es aufgebauscht wird, jeder kleine Ruckler sofort als MR abgetan wird oder auch andere Dinge die garnichts miteinander zu tun haben wie enginebedingte Ruckler, SSAA-Lag, Profile-Bugs etc. darunter fallen.
Und hier muss man unterscheiden, nur wird das kaum getan... die Leute bewusst abgeschreckt, die Finger davon zu lassen.
Ailuros
2012-10-28, 17:12:09
Was für Vorraussetzungen gegenüber jetzt müssen denn erfüllt werden, dass das ginge?
Echtes R&D vielleicht? Kostet AFR etwas in hw Entwicklung oder sogar Forschung?
aufkrawall
2012-10-28, 17:23:01
Echtes R&D vielleicht? Kostet AFR etwas in hw Entwicklung oder sogar Forschung?
Das ist jetzt aber nur ein educated guess, oder? ;)
Ich denke schon, dass die Profilpflege und das ständige Erinnern von Spieleentwicklern, die Technik mit AFR kompatibel zu halten, etwas ist, das man lieber heute als morgen loswerden würde.
Ailuros
2012-10-28, 17:30:42
Irgendwann wird das sicher kommen, aber ich glaube nicht zeitnah.
Das ist eher relativ ob IHVs es erst zum Zeitpunkt loesen wollen wo es wirklich nicht mehr weiter geht oder etwas vorsorgen werden bevor es zu spaet ist. Zwar hat NV ihre Strategie fuer single chip high end geaendert aber offiziell kommt der 550mm2 Brummer mit 10 Monaten Verspaetung gegenueber Tahiti und das nichtmal in anstaendigem Volumen. Besser wird es nicht werden in der Zukunft nur schlimmer.
Was mich an der ganzen MR-Geschichte stört, das so ziemlich alles darunter fällt, es aufgebauscht wird, jeder kleine Ruckler sofort als MR abgetan wird oder auch andere Dinge die garnichts miteinander zu tun haben wie enginebedingte Ruckler, SSAA-Lag, Profile-Bugs etc. darunter fallen.
Und hier muss man unterscheiden, nur wird das kaum getan... die Leute bewusst abgeschreckt, die Finger davon zu lassen.
Der Punkt ist dass wenn kein Druck von den zukuenftigen Notwendigkeiten von professionellen Maerkten kommt werden IHVs wohl schwer etwas daran aendern, eben weil das mGPU Publikum die groesste Minderwertigkeit ist. Eine jegliche anstaendige hw basierende mGPU Loesung so wie ich sie mir vorstelle wuerde sich nicht anders verhalten als ein multi-cluster config auf einem einzelnem chip.
Das Publikum laesst die Finger davon aus einfacherem Grund: nicht jeder hat den Luxus 800-1000 Euro nur fuer eine GPU hinzulegen. Dahingegen ist es stinknormal dass das Publikum fuer mGPU so klein ist.
Im Fall wo es so weit kommt wie ich mir erhoffe werden die single chip high end User sowieso keine andere Loesung haben wenn sie wirklich eine enthusiast mGPU haben wollen.
Das ist jetzt aber nur ein educated guess, oder? ;)
Nicht wirklich.
Ich denke schon, dass die Profilpflege und das ständige Erinnern von Spieleentwicklern, die Technik mit AFR kompatibel zu halten, etwas ist, das man lieber heute als morgen loswerden würde.
Was genau hat sw Unterstuetzung nochmal mit hw R&D bzw. zusaetzlicher hw Logik genau zu tun? Das Treiberteam hat es als Aufgabe genau das zu tun was Du oben beschreibst. Ausser Du glaubst natuerlich dass beide IHVs "spezielle" sw engineers nur fuer den AFR Scheiss eingestellt haben und diese NICHTS anderes taeglich anstellen als sich nur mit diesem zu beschaeftigen.
boxleitnerb
2012-10-28, 17:37:01
Wie soll sowas jemals kommen, wenn man die Flexibilität verliert?
Zwei "kleine" Karten kann ich auch an zwei einzelne Leute verkaufen und muss kein spezielles Produkt auflegen. Die, die sie einzeln kaufen, zahlen 500 Piepen, die Enthusiasten halt 2x500.
Nur für ein SKU a la GTX690/HD7990 würde man doch nicht das ganze Trara machen, zumal da an den GPUs wohl einiges geändert werden müsste, oder? Stelle ich mir aufwändiger vor als "einfach" eine 690 zu kreieren. Das wäre ja nur dann interessant, wenn man es auch bei kleineren Chips anbieten könnte. Also statt einer 680 mit GK104 hätte man dann eine 680 mit 2x GK106 oder sowas in der Art. Wobei mir grad nicht klar ist, ob das überhaupt Vorteile hat, nur noch kleine Bausteine zu fertigen und dann auf eine Karte 2, 4, 8 davon draufzusetzen.
aufkrawall
2012-10-28, 17:40:42
Was genau hat sw Unterstuetzung nochmal mit hw R&D bzw. zusaetzlicher hw Logik genau zu tun? Das Treiberteam hat es als Aufgabe genau das zu tun was Du oben beschreibst. Ausser Du glaubst natuerlich dass beide IHVs "spezielle" sw engineers nur fuer den AFR Scheiss eingestellt haben und diese NICHTS anderes taeglich anstellen als sich nur mit diesem zu beschaeftigen.
Wieso sollten die IHVs freiwillig Ressourcen für Blödsinn verballern?
Besonders vor dem Hintergrund, dass sie sich immer mehr Zeit mit den Treibern nehmen müssen.
Immerhin skaliert AFR bei voller Auslastung an die 100%, auch in Relation zum Energiebedarf.
Ailuros
2012-10-28, 21:58:57
Wie soll sowas jemals kommen, wenn man die Flexibilität verliert?
Zwei "kleine" Karten kann ich auch an zwei einzelne Leute verkaufen und muss kein spezielles Produkt auflegen. Die, die sie einzeln kaufen, zahlen 500 Piepen, die Enthusiasten halt 2x500.
Nur für ein SKU a la GTX690/HD7990 würde man doch nicht das ganze Trara machen, zumal da an den GPUs wohl einiges geändert werden müsste, oder? Stelle ich mir aufwändiger vor als "einfach" eine 690 zu kreieren. Das wäre ja nur dann interessant, wenn man es auch bei kleineren Chips anbieten könnte. Also statt einer 680 mit GK104 hätte man dann eine 680 mit 2x GK106 oder sowas in der Art. Wobei mir grad nicht klar ist, ob das überhaupt Vorteile hat, nur noch kleine Bausteine zu fertigen und dann auf eine Karte 2, 4, 8 davon draufzusetzen.
Die Idee ist eher dass man um Entwicklungszeiten zu verkuerzen bei ca. 70-75% von der maximalen Toleranz jeglichem Herstellungsprozesses halt macht und anstatt single chip high end einfach enthusiast via mGPU bedient. Eines der theoretischen Nachteile waere dass der chip voll HPC faehig sein muesste und die hw scheduling Logik noch etwas zusaetzlich kostet aber man spart sich die uebermaessig grossen R&D und Herstellungskosten fuer einen 530-575mm2 grossen die und auch die zunenehmenden Herstellungs-verzoegerungen. Heute ist es ein Jahr von einer performance SKU (GK104) bis zu desktop GK110 (wenn alles nach Plan laeuft blah blah blah). Wie wird es wohl unter <20nm genau aussehen wenn es so weiter geht? 1.5-2 Jahre? Irgend etwas muessen sich die IHVs einfallen lassen denn Herstellungsprozesse werden leider nicht besser. Wird wohl auch nicht morgen oder sogar unter 20nm passieren.
Wieso sollten die IHVs freiwillig Ressourcen für Blödsinn verballern?
Weil eine Kombination von sw und hw stets um zich Male effizienter ist und auch das Leben von jeglicher Treiber und sw Entwicklung um zich Male leicher machen koennte vielleicht?
Besonders vor dem Hintergrund, dass sie sich immer mehr Zeit mit den Treibern nehmen müssen.
Siehe oben.
Immerhin skaliert AFR bei voller Auslastung an die 100%, auch in Relation zum Energiebedarf.
Nur unter bestimmten Vorraussetzungen und auch nicht immer. Stell Dir vor man bezahlt bei heutigen mGPUs fuer den doppelten Speicher bzw. Bandbreite, obwohl es eigentlich N/2 Speicher und N/2 Bandbreite pro alternating frame sind bei 2 cores pro mGPU; so viel was den Energiebedarf betrifft.
aufkrawall
2012-10-28, 22:35:01
Stell Dir vor man bezahlt bei heutigen mGPUs fuer den doppelten Speicher bzw. Bandbreite, obwohl es eigentlich N/2 Speicher und N/2 Bandbreite pro alternating frame sind bei 2 cores pro mGPU; so viel was den Energiebedarf betrifft.
Ich wollte darauf hinaus, dass Refreshs/neue Generationen es nicht immer 1:1 schaffen, den gestiegenen Strombedarf in Leistung umzusetzen.
Cayman etwa war doch relativ mies und GF100 war auch unglücklich.
(So gesehen scheinen mir Tahiti und GK104, wegen dem nicht immer so großen Leistungssprung, schlechter gemacht zu werden als sie sind.)
Im Übrigen könnte ich zig Beispiele posten, wo mit sGPU im Vergleich zu 2-Way immer nur noch so ziemlich die Hälfe der fps rauskommen, jüngstes Beispiel AMD Leo Demo (100% Skalierung bei Min-fps).
Natürlich wär eine mGPU-Lösung toll, die auch ohne Limit die Frames regelmäßig rausgibt und es keine Probleme mehr mit gesonderten Profilen gäbe.
Was für Vorraussetzungen gegenüber jetzt müssen denn erfüllt werden, dass das ginge?
Shared Memory mit ordentlicher Bandbreite, sprich Interconnect zum anderen Chip mit etwa gleicher Bandbreite wie zum Speicher.
Thunder99
2012-10-28, 23:12:46
RadeonPro schafft immer mehr einen Mehrwert für AMD/ATI GPU´s . Finde es echt Top das es dort bald vergleichbare Eigenschaften gibt was man alles einstellen kann :)
Zum Thema (was ja OT ist?!) AFR: Wenn hat nvidia was in der Schublade wie es anders geht dank 3dfx...
Zum Thema (was ja OT ist?!) AFR: Wenn hat nvidia was in der Schublade wie es anders geht dank 3dfx...
Was 3Dfx damals gemacht hat ist schon seit Jahren nicht mehr verwendbar.
aufkrawall
2012-10-28, 23:24:25
Shared Memory mit ordentlicher Bandbreite, sprich Interconnect zum anderen Chip mit etwa gleicher Bandbreite wie zum Speicher.
Würd dafür nicht ziemlich viel Platz aka Transistoren draufgehen?
Wäre dann ja von der Effizienz her eher schlechter als AFR.
Wobei, wenn die IHVs wirklich weiterhin so Probleme mit großen Chips haben bzw. das noch zunimmt, könnte das doch noch interessant werden.
Wär aber kein Ersatz für AFR, denn das macht man schließlich auch nur, wenn einem die sGPU-Leistung (oder dann halt "echte" mGPU-) nicht reicht.
Würd dafür nicht ziemlich viel Platz aka Transistoren draufgehen?
NVIDIA hat da ein Patent einen Teil des Speicherinterfaces dafür zu verwenden.
AFR ist nicht wirklich effizient, weil man öfters Buffer umkopieren muss. Das würde völlig entfallen, die Skalierung wäre immer gleich gut.
Jegliche Relativierung koennte sogar erwuenscht sein um die jeweilige Schwaechen bzw. Staerken der einen oder anderen Loesung zu definieren. Wenn Du etwas nutzvolleres und sachliches zum Thema beizutragen hast als das obrige eher ueberfluessige, ist es natuerlich mehr als willkommen.
Je nach Perspektive wird es auch unterwertet. So bald beide IHVs durch den wachsenden Herstellungsprozess-Stress keinen anderen Ausweg mehr finden koennen werden sie an eine hw-basierende echte mGPU Loesung denken muessen (ueberhaupt fuer professionelle Maerkte) und dann erzaehlen uns die jeweiligen Marketing-/PR-Abteilungen was fuer ein bekloppter sw hack AFR wirklich war.
Ich fürchte du hast den Artikel auf THG nicht gelesen. Hier steht, dass es bei AMD MIT Framelimiter besser gestellt ist als bei NV. Von daher geht aller Diskussion was anschließend geschah obsolet und komplett am Threadtitel vorbei.
Blaire
2012-10-29, 01:18:19
Adaptives Vsync und FPS-Limiter sind aber nicht das Gleiche...
Ailuros
2012-10-29, 07:17:54
Was 3Dfx damals gemacht hat ist schon seit Jahren nicht mehr verwendbar.
Eine primitivere Variante von AFR verwendete im desktop als erste die ATI Rage Fury MAXX.
Sonst kommt die Verwirrung dass NVIDIA ein aehnliches acronym fuer mGPU verwendet hat wie damals 3dfx. Die Idee aber wieder auf mGPU zu steigen kam bei NV schon von den ex-3dfx engineers, nur eben ganz anders realisiert.
3dfx SLI = scan line interleaving
NV SLi = scalable link interface
Ich fürchte du hast den Artikel auf THG nicht gelesen. Hier steht, dass es bei AMD MIT Framelimiter besser gestellt ist als bei NV. Von daher geht aller Diskussion was anschließend geschah obsolet und komplett am Threadtitel vorbei.
Ich hab den Artikel als erstes gelesen vor dem eigentlichen thread hier und wie Blaire eben notiert handelt es sich eben NICHT um einen reinen Framelimiter. Ich hab nirgends erwaehnt oder angedeutet dass die Methode nichts bringt, es aendert aber nichts an der Tatsache dass AFR nicht das gelbste vom Ei ist wenn es zu mGPU Effizienz kommt und das ist ziemlich IHV-agnostic. Anders das eigentliche Problem mit AFR wird damit nicht beseitigt.
Der erste Paragraph in meiner vorigen Antwort war eine Reaktion zu einem klaren Troll-versuch der gar nichts mit dem Thema zu tun hat. Fuer den spezifischen Fall ob als modtext designiert oder nicht stehen moderative Entscheidungen eben nicht zur Debatte frei laut Regeln.
Was jetzt den OT Verlauf des Threads betrifft ich kann gerne alles irrelevante in einen neuen Thread verschachteln, nur bleiben dann nur eine handvoll an Beitraegen fuer das Thema dann eigentlich uebrig.
Ich wollte darauf hinaus, dass Refreshs/neue Generationen es nicht immer 1:1 schaffen, den gestiegenen Strombedarf in Leistung umzusetzen.
Das stimmt schon generell; ergo wird es mit der zunehmenden Problematik von Herstellungsprozessen besser oder schlimmer werden?
Cayman etwa war doch relativ mies und GF100 war auch unglücklich.
Cayman war fuer 32nm geplant und man hat an dem nicht besonders viel geaendert deshalb ist der Stromverbrauch auch gestiegen im Vergleich zu Cypress, obwohl er sich bei GF110 mit einem SM mehr und 10% hoeherem Takt sich sogar leicht gesenkt hat.
GF100 hat ein hw die interconnect Problem. Beide der obrigen Beispiele sind nicht representativ dafuer.
(So gesehen scheinen mir Tahiti und GK104, wegen dem nicht immer so großen Leistungssprung, schlechter gemacht zu werden als sie sind.)
Beide haben einen mehr als gesunden Leistungssprung im Vergleich zu Cayman bzw. GF114.
Im Übrigen könnte ich zig Beispiele posten, wo mit sGPU im Vergleich zu 2-Way immer nur noch so ziemlich die Hälfe der fps rauskommen, jüngstes Beispiel AMD Leo Demo (100% Skalierung bei Min-fps).
Leo ist ein techdemo fuer forward rendering um vorzuzeigen dass es auch Alternativen gibt zu "typischem" deferred rendering womit Kombinationen mit MSAA zumindest umstaendlich sein koennen wenn nicht zu Leistungs-fressend. Mehr dazu hier: http://forum.beyond3d.com/showpost.php?p=1617012&postcount=30
Der Ironie zu Liebe je mehr irgendwelche Art von deferred rendering bzw. post processing in Spiele kommen desto schwerer wird AFR Skalierung.
NVIDIA hat da ein Patent einen Teil des Speicherinterfaces dafür zu verwenden.
AFR ist nicht wirklich effizient, weil man öfters Buffer umkopieren muss. Das würde völlig entfallen, die Skalierung wäre immer gleich gut.
Nachtrag: Zwei Chips auf einem Silicon Interposer wird in Zukunft viel höhere Geschwindigkeiten erlauben. Dann wird die Sache schon deutlich lohnenswerter.
M4xw0lf
2012-10-29, 21:13:38
RadeonPro bekommt wohl noch weitere (bisher noch unbekannte) Funktionen: http://forums.guru3d.com/showpost.php?p=4441191&postcount=6018
The new preview build is taking a bit longer than expected, but I'm sure you're gonna forgive me for postponing it so long... all I can say now it's that an unexpected surprise is coming, you won't regret waiting for it
AMD scheint auch die Zusammenarbeit mit dem Entwickler zu intensivieren.
boxleitnerb
2012-10-29, 21:15:27
Find ich gut, das braucht AMD, um wieder Enthusiasten "Mindshare" zu bekommen. Solche Tweaktools sind höchst willkommen.
aufkrawall
2012-10-29, 21:21:12
Definitiv.
RadeonPro basiert aber wohl immer noch auf Hooks zur App Detection?
Wäre schön, wenn dies auch über die API vom CCC gelöst werden könnte, zumindest als Option.
aufkrawall
2012-10-31, 17:55:53
Leo ist ein techdemo fuer forward rendering um vorzuzeigen dass es auch Alternativen gibt zu "typischem" deferred rendering womit Kombinationen mit MSAA zumindest umstaendlich sein koennen wenn nicht zu Leistungs-fressend. Mehr dazu hier: http://forum.beyond3d.com/showpost.php?p=1617012&postcount=30
Der Ironie zu Liebe je mehr irgendwelche Art von deferred rendering bzw. post processing in Spiele kommen desto schwerer wird AFR Skalierung.
Bei welchem Spiel mit Deferred Renderer soll die Skalierung denn leiden?
Ich hab mal Metro 2033 gebencht (1080p, vollste Details, CPU-PhysX).
sGPU:
Frames: 2194 - Time: 60000ms - Avg: 36.567 - Min: 27 - Max: 45
2-Way SLI:
Frames: 4146 - Time: 60000ms - Avg: 69.100 - Min: 50 - Max: 84
Ist jetzt auch nicht so weit von 100% entfernt. ;)
Find ich gut, das braucht AMD, um wieder Enthusiasten "Mindshare" zu bekommen. Solche Tweaktools sind höchst willkommen.
Stimmt das kann man gar nicht genug hervorheben.
Ailuros
2012-10-31, 22:57:42
Bei welchem Spiel mit Deferred Renderer soll die Skalierung denn leiden?
Ich hab mal Metro 2033 gebencht (1080p, vollste Details, CPU-PhysX).
sGPU:
Frames: 2194 - Time: 60000ms - Avg: 36.567 - Min: 27 - Max: 45
2-Way SLI:
Frames: 4146 - Time: 60000ms - Avg: 69.100 - Min: 50 - Max: 84
Ist jetzt auch nicht so weit von 100% entfernt. ;)
Deferred rendering != deferred shading bzw. lighting. Die 4A hat ein paar clevere tricks fuer die letzten beiden welche auch MSAA im Gegensatz zu STALKER/X-ray engine erlauben.
Unter der Logik dass man in Metro sich in der Mehrzahl des Spiels in einer dunklen indoor Umgebung bewegt macht die engine so wie sie ausgelegt ist auch voll Sinn.
aufkrawall
2012-10-31, 23:27:56
Deferred rendering != deferred shading bzw. lighting. Die 4A hat ein paar clevere tricks fuer die letzten beiden welche auch MSAA im Gegensatz zu STALKER/X-ray engine erlauben.
Ah, ups
*edit*
Das MSAA von Metro greift auch nicht sehr gut, versagt eigentlich bei den meisten Lichtquellen.
Welches Spiel sollte ich denn mal benchen?
Ich hab schon Trine 2 probiert, das skaliert mit SSAA auch zu ~100%.
Ailuros
2012-11-01, 00:46:50
Was willst Du buntes benchen und um was genau zu sehen? Fuer was deferred-wasauchimmer und auch alternate frame rendering steht ist nicht allzu schwer im Netz nachzulesen. Natuerlich kann man es unter Umstaenden umgehen mit einigen tradeoffs, aber der eigentliche brennende Punkt hier ist ob und wie lange es damit weitergehen kann.
aufkrawall
2012-11-01, 00:53:53
Was willst Du buntes benchen und um was genau zu sehen? Fuer was deferred-wasauchimmer und auch alternate frame rendering steht ist nicht allzu schwer im Netz nachzulesen. Natuerlich kann man es unter Umstaenden umgehen mit einigen tradeoffs, aber der eigentliche brennende Punkt hier ist ob und wie lange es damit weitergehen kann.
So wie du es dargestellt hast, klingt es so, als ob man mit SLI ganz allgemein schlechtere Skalierung mit Deferred Rendering hat.
Ohne konkrete Beispiele ist das aber leider nur Bashing, das wahrscheinlich nicht ganz der Wahrheit entspricht.
Ailuros
2012-11-01, 17:45:37
So wie du es dargestellt hast, klingt es so, als ob man mit SLI ganz allgemein schlechtere Skalierung mit Deferred Rendering hat.
Ohne konkrete Beispiele ist das aber leider nur Bashing, das wahrscheinlich nicht ganz der Wahrheit entspricht.
Dann frag halt einen Entwickler inwiefern das Ganze genau bashing ist. Noch besser einen engineer der sich mit der Entwicklung von Algorithmen beschaeftigt.
Es gibt tonnenweise Referenzen dafuer z.B. im B3D forum und nur ein schnelles und ziemlich altes Beispiel:
http://forum.beyond3d.com/showthread.php?t=49199&highlight=mGPU
For AFR based schemes, persistent data is the number one killer of scaling performance. The need to duplicate the memory for each chip is also a major cost concern.
Eine alternative Loesung waere einfach single frame rendering wo jeglicher frame in macro tiles aufgeteilt wird und via hw scheduling auf die jeweiligen cores verteilt wird. Gibt es jetzt zwischen den cores noch eine direkte Verbindung desto besser.
Noch besser wie MfA auf der zweiten Seite andeutet wenn alles stimmt ist das hw scheduling bzw. load balancing bei einer guten hw Loesung nicht besonders ineffizienter als hw scheduling/load balancing zwischen clusters auf einem einzelnen chip.
AFR hat keine schlechtere Skalierung mit deferred rendering generell mit den workarounds die Entwickler momentan einsetzen. Aber tradeoffs bzw. workarounds sind auch stets nur gut fuer begrenzte Faelle.
Eine andere Frage: wuerdest etwas dagegen haben gegen eine um zich Male effizientere und teilweise billigere mGPU Loesung? In dem Sinn wuerde ich an Deiner Stelle etwas darueber nachforschen denn einfach zu denken dass ich ein eingebildeter Spinner bin der mir nichts dir nichts recht haben muss, ist eben nur die einfache Loesung. Schick mal eine PM an Demirug als einfaches Beispiel und lass Dich ueber die Antwort ueberraschen.
aufkrawall
2012-11-01, 17:56:52
Dann frag halt einen Entwickler inwiefern das Ganze genau bashing ist. Noch besser einen engineer der sich mit der Entwicklung von Algorithmen beschaeftigt.
Es gibt tonnenweise Referenzen dafuer z.B. im B3D forum und nur ein schnelles und ziemlich altes Beispiel:
http://forum.beyond3d.com/showthread.php?t=49199&highlight=mGPU
Eine alternative Loesung waere einfach single frame rendering wo jeglicher frame in macro tiles aufgeteilt wird und via hw scheduling auf die jeweiligen cores verteilt wird. Gibt es jetzt zwischen den cores noch eine direkte Verbindung desto besser.
Noch besser wie MfA auf der zweiten Seite andeutet wenn alles stimmt ist das hw scheduling bzw. load balancing bei einer guten hw Loesung nicht besonders ineffizienter als hw scheduling/load balancing zwischen clusters auf einem einzelnen chip.
AFR hat keine schlechtere Skalierung mit deferred rendering generell mit den workarounds die Entwickler momentan einsetzen. Aber tradeoffs bzw. workarounds sind auch stets nur gut fuer begrenzte Faelle.
Will nicht abstreiten, dass das mit AFR schwieriger/nachteilbehafteter ist. Mir geht es nur um konkrete Beispiele, wo man als mGPU-User allgemein Nachteile in Form schlechterer Skalierung hat.
Der Rest interessiert mich doch nur am Rande. Bin ja nur Enduser und AFR ist eh keine relevante Marktgröße bzw. es zahlt sich eher durchs Marketing aus.
Ich glaube also nicht, dass ich als Käufer irgendwelche Entwicklungen blockiere.
Eine andere Frage: wuerdest etwas dagegen haben gegen eine um zich Male effizientere und teilweise billigere mGPU Loesung?
Wieso sollte ich? Ich würd auch AFR aufgrund seiner Nachteile sofort durch etwas Besseres ersetzen.
Momentan gibts das halt nur nicht.
In dem Sinn wuerde ich an Deiner Stelle etwas darueber nachforschen denn einfach zu denken dass ich ein eingebildeter Spinner bin der mir nichts dir nichts recht haben muss, ist eben nur die einfache Loesung.
Hab ich ja nicht getan bzw. würde ich auch nicht. ;)
Ich denke, du hast ein paar Äußerungen von mir missverstanden.
Btw: Mir ist gerade zum ersten Mal der AFR-Lag störend aufgefallen, bei Far Cry 2 mit Vsync. Falls es dich tröstet. :D
Dafür rennts halt mit 8xSGSSAA bei konstant 100fps, mit Limiter ist der zusätzliche Input-Lag dann quasi wieder weg.
Man muss halt mit AFR etwas tricksen, aber das muss gar nicht so schlimm sein.
Ich brauche ja bloß ausprobieren, wie es mit Single-GPU im Vergleich läuft. Dann weiß man, woran man ist.
HarryHirsch
2012-11-02, 21:56:29
Deferred rendering != deferred shading bzw. lighting. Die 4A hat ein paar clevere tricks fuer die letzten beiden welche auch MSAA im Gegensatz zu STALKER/X-ray engine erlauben.
Unter der Logik dass man in Metro sich in der Mehrzahl des Spiels in einer dunklen indoor Umgebung bewegt macht die engine so wie sie ausgelegt ist auch voll Sinn.
die xray kann sehr wohl msaa, allerdings erst ab cs.
um den rest von dem grünen freak zu beantworten fehlt mir die muse.
ignoring is power!
aufkrawall
2012-11-02, 22:03:19
um den rest von dem grünen freak zu beantworten fehlt mir die muse.
Du hast doch gar keine Antworten parat. Da würde eh nichts kommen, worauf die Welt wartet. :tongue:
HarryHirsch
2012-11-02, 22:07:44
eine Antwort hab ich. ob die Welt darauf wartet? keine Ahnung.
Fakt ist, man sollte dich in deiner Welt leben lassen.
ls ging genau den selben weg. ;)
aufkrawall
2012-11-02, 23:56:27
Versuch doch mal, meine Aussagen zu entkräften. Mit Argumenten, falls du weißt, was das ist.
So ist das einfach nur wie Vera am Mittag.
M4xw0lf
2012-11-08, 09:09:58
Der neue Build von RP steht vor der Tür und kommt auch für Win8 32- und 64-bit Anwendungen:
Hey guys, this saturday 11/10 I'll publish the newest RP build, there's lots and lots of changes and RP is now compatible with Windows 8 for both 32 and 64-bit apps.
http://forums.guru3d.com/showpost.php?p=4449427&postcount=6048
Ich bin auf die "lots and lots of changes" gespannt :popcorn:
M4xw0lf
2012-11-18, 20:01:27
Mal wieder was neues von RP: möglicherweise gibts bald SSAO (HBAO) zumindest under DX9. http://forums.guru3d.com/showpost.php?p=4456508&postcount=6417
Knuddelbearli
2012-11-18, 20:06:36
wie wärs mal mit nem eigenen thread dazu ? finde ich eh ein unding das es keinen dazu gibt ...
M4xw0lf
2012-11-18, 20:18:08
Es könnte ja einfach jemand diesen Fred umbenennen. "RadeonPro bringt cooles Zeug für Radeons", sowas in der Art ;)
Coole Sache, wenn er's hinkriegt. Momentan scheint es mal eben die Framerate zu dritteln auf den Screenshots xD
Ronny145
2012-11-18, 21:43:04
wie wärs mal mit nem eigenen thread dazu ? finde ich eh ein unding das es keinen dazu gibt ...
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=484074&highlight=radeonpro
M4xw0lf
2012-11-18, 21:59:30
Coole Sache, wenn er's hinkriegt. Momentan scheint es mal eben die Framerate zu dritteln auf den Screenshots xD
Da ist ein zweiter FPS-Counter im OSD link unten, der sagt 25% weniger FPS ^^
Der extra-Counter spinnt öfter mal rum, tanzt wild herum wie es ihm gefällt - war zumindest in einigen der letzten Preview-Versionen von RP der Fall.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.