|
|
|
|
|
|
|
Wobei man dazu sagen muss, dass das die normalen Märkte nicht tangiert hat und GDAX mit seinen Mechanismen ein besonders heißes Eisen ist.
Wer hoch pokert kann halt auch hoch verlieren.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TheRealHawk am 22.06.2017 16:30]
|
|
|
|
|
|
|
|
|
Aus dem Grund würde ich da eher vorsichtig sein mit Spekulatius und Co.
Also ne sichere Anlageform ist das sicher nicht, genau so wenig wie der Klopapier-Euro.
Zum spielen ganz OK.
Ne kleine Renderfarm würde ich mir da aber nicht aufstellen, außer man hat ne Möglichkeit zum Nulltarif an Strom zu kommen. 
Imerhin muss man dann im Winter nicht mehr heizen. Und mit einem Wärmetauscher könnte man mit GPU-Kühlwasser duschen.
Der Traum eines jeden Nerds. 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Volta for Gaming is dead?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Die kommenden RX-Vega-Karten von AMD sollen zwar (unter erheblichem Energieeinsatz) mithalten."
Ist das schon bekannt, ja?
|
|
|
|
|
|
|
|
|
|
|
|
ja, soll wohl um die 300W schlucken unter Volllast
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ich finde das schön, dass die da eine abstruse übersetzung verbreiten, die nichts mit dem zu tun hat, was die person tatsächlich gesagt hat.
gesagt wurde "die karten verbraucht so viel wie nötig" und das man das in relation zur leistung der karte sehen muss.
das ist eine so generische aussage, wie es nur irgendwie möglich ist.
davon abgesehen, dass die karte mehr strom fressen wird als die von nvidia sollte klar sein, weil sie mehr hardware mitschleppt, die mehr macht und mehr möglich macht.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://disqus.com/by/klaudiuszkaczmarzyk/
Vega FE Benchmarks.
Der Versuch ohne ordentliche Treiber und abgeschalteten Hardwarefeatures wie Tile Based Rendering die Performance der Karte herauszufinden.
Bisher ist sie bei 1070 bis knapp über 1080 Performance und viel Stromverbrauch.
Finde ich sehr vielversprechend.
Wie seht ihr das?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von da gig
Wie seht ihr das?
| |
| | Zitat von TheRealHawk
Wenn die Leistung stimmt nehm ich das gerne mit, Wakü drauf, soll der Kram sich 1000W gönnen.
| |
|
|
|
|
|
|
|
|
|
|
|
|
so lange das nicht unbedingt ne 295X2 wird... wobei die karte nicht schlecht war. so von der raw leistung her.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Der große Wurf wird Vega sicher nicht, sonst hätten sie das schon lange durchscheinen lassen. Vielleicht kommt man mit Ach und Krach über GP102, dann aber mit höherem Stromverbrauch und allem was damit einhergeht. Dann können sie natürlich den Preis niedrighalten, aber an Marge bleibt dank HBM2 nicht viel hängen.
|
|
|
|
|
|
|
|
|
|
|
ihr vergesst da immer den fakt, dass das die einzige karte auf dem markt sein wird, neben den konsolen, die FP16 in double speed kann.
das ist einer der gründe, warum die konsolen 4k überhaupt befeuern können. die entwickler können da nahezu alles von den konsolen übernehmen, ohne grosse änderungen, und können dann einfach die qualitätsschraube weiter aufdrehen. so 10 tflop (console) vs. 25 tflop (vega) half precision...da geht dann schon ein wenig was.
man sollte bitte auch nicht vergessen, dass die ursprüngliche GCN architektur damals auch nicht unbedingt für ihre pixel push performance bekannt war, sondern für die technischen sachen, die damit auf einmal gingen. es würde mich nicht wundern, wenn das hier nicht wesentlich anders kommen wird.
das ist dann aber effektiv das, was ich seit inzwischen mehreren jahren sage und auf "intelligent vs dump but fast" hinausläuft. ersteres ist für die entwickler auf lange sicht interessanter. es hat da schon gründe, warum kaum ein entwickler irgendwas wirklich negatives über die GCN sachen sagt. die wollen einfach nur mehr möglichkeiten, damit man die algorithmen vernünftiger umsetzen kann und hier gewinnt selbst die ur GCN architektur gegenüber pascal.
so als konsument sollte man vielleicht auch mal drauf schauen, wie viele studios und publisher inzwischen mit amd arbeiten, die früher mehr oder weniger nvidia exklusiv waren. die einzigen die aktuell noch primär nvidia sind ist ubisoft. alle anderen sind entweder komplett neutral oder nutzen amds entwickler service.
zugegeben, letzteres hat auch damit zu tun, dass man bei amd nicht tausende von NDAs unterschreiben muss und die einfach offener mit den informationen sind, die man als entwickler braucht. mal ganz zu schweigen davon, dass man zugriff auf den source code der amd libraries hat...
hier muss man bedenken, dass kaum irgendwas von den gameworks sachen auf den konsolen läuft und man dafür immer nen extra pfad in die engine stopfen muss. läuft dann was nicht rund, dann bekommt der engine / spiele hersteller den arsch aufgerissen und nicht nvidia. der entwickler kann in dem fall nur zwei dinge tun, entweder den gameworks kram entfernen, was nicht immer möglich ist, je nach vertrag oder aber hoffen und beten, dass nvidia sich erbarmt und den scheiss fixt. andernfalls wars das mit deiner (entwickler) reputation.
|
|
|
|
|
|
|
|
|
|
|
|
Mit dem Angriff Koduris wird das alles in Ordnung kommen.
|
|
|
|
|
|
|
|
|
|
|
Einfache Logik: wäre Vega wirklich so lahm wie es jetzt aussieht, hätte AMD keine Fortschritte im Vergleich zu Fiji gemacht.
Ist halt einfach nur wieder so ein typischer AMD-Dreckslaunch.
|
|
|
|
|
|
|
|
|
|
|
nen dreckslaunch ist das nicht. die FE ist halt keine spieler karte und das scheinen so einige leute wohl mal wieder vergessen zu haben. amd hat das wohl nicht zu unrecht zig mal gesagt, dass die karte eine andere kundschaft ansprechen soll.
so nebenbei, alle "pro" karten laufen langsamer als die zocker karten. dafür haben die sehr viel stabilere und konformere treiber, was in dem segment einfach wichtiger ist, als die maximale performance.
das spiel hat man bei den amd (ehemals?) firepro karten, dann bei nvidias quadro karten und bei intels Pxxxx IGPs. letztere hab ich hier in einem meiner rechner und die läuft so ca. 5% langsamer als die gleiche nicht P version. dafür kann der treiber einige sachen mehr, die der nicht P treiber nicht kann. (ich brauche davon mal so genau gar nichts.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
achja, der gute fuckup von kanter... mal wieder.
ja, david ist eigentlich gut informiert und weiss auch eine ganze menge über hardware. in diesem speziellen artikel hat er aber sehr grobe fehler gemacht.
das programm, was er da für die tests genutzt hat, macht nichts anderes als ein full-screen dreieck zu zeichnen. dabei wird in dem shader der prozess etwas serialisiert, damit du sehen kannst wie die karte etwas rendert.
das problem hier ist, dass es die rasterization order zeigt und nicht irgendein tiling. das tiling ergibt sich primär darauf, dass die shader in genau der reihenfolge und art ihre aufgaben erledigen. das wiederum macht noch keinen TBR oder TBDR rasterizer aus. nebenbei, machen alle GCN chips nichts anderes als genau das, sie rastern in bins, die per zufall die grösse ihres lokalen caches haben, damit sie nicht auf den viel langsameren VRAM zugreifen müssen.
kurzer ausflug zu den unterschieden, weil in dem hier verlinkten artikel auch ein paar sachen durcheinander geworfen wurden.
TBR => Tile Based Rendering
TBDR => Tile Based Deferred Rasterization
IMR => Immediate Mode Rendering
1. der unterschied zwischen rendering und rasterization, ist das ersteres alles inkl. der kompletten geometrie und texture pipeline einschliesst, wohingegen letzteres lediglich die umsetzung von geometrie in pixel meint.
das eine ist der komplette prozess um ein bild zu erschaffen und letzteres ist der eigentliche vorgang bei dem pixel in korrekten farben generiert werden.
2. der unterschied zwischen tile-based und immediate mode ist, dass IMR renderer im klassischen stil arbeiten, also in einer art von scanline mode. dabei werden einzelne zeilen des kompletten bildes nacheinander rasterized.
im fall von tile-based methoden wird das bild in so genannte tiles runtergebrochen, die sind in aller regel so gross, dass sie im chip lokalen (auch bekannt als cache) speicher bleiben können, für die komplette arbeit. diese tiles werden dann nach einander rasterized und hinterher wieder "zusammengesetzt".
IMR ist die klassische art zu rastern, der vorteil ist, alles verhält sich wie erwartet, sachen die übereinander von hinten nach vorne gerendert werden bleiben in der reihenfolge und deine shader werden entsprechend abgearbeitet, weil sie in genau der reihenfolge zum treiber geschickt werden.
TBR ist schneller, wenn richtig umgesetzt und nichts anderes limitiert. hier gibt es aber ein paar kleinere und grössere sachen, auf die man achten muss. bedingt durch das tiling kann es passieren, dass die reihenfolge modifiziert wird, was zu fehlerhaften rasterizations führen kann.
3. der unterschied zwischen TBR und TBDR ist, dass TBR nach wie vor forwärts abläuft also nicht viel gecached wird. das wiederum ist der grund, warum kaum eine mobile architektur TBR nutzt, aber fast alle TBDR nutzen.
bei TBDR aka tile-based deferred rasterization wird der ganze prozess so umgebaut, dass alle schritte unabhängig von einander laufen können. das wiederum hat zur folge, dass der ganze prozess in unvorhersehbarer reihenfolge abläuft. man kann sich hier also nicht mehr drauf verlassen, dass pixel a vor pixel b gerastert wird und das man dann auf diesen pixel zugreifen kann.
wer sich noch an die Kyro karten von anfang der 2000er erinnert, der erinnert sich vielleicht auch noch daran, dass die manchmal dazu neigten diverse teile eine szene nicht sauber zu rendern. dort fehlten dann einfach sachen, weil teile in falscher reihenfolge gerastert wurden.
die karte bzw. der chip hat TBDR eingesetzt.
das ganze war eine schöne demonstration, dass ein sehr viel schwächerer chip sehr viel mehr leisten kann, wenn man es intelligent angeht.
das problem ist nur, dass du zwar eine gewaltige performance im bereich der pixel workload bekommst, aber alles andere den bach runter geht und du dir ne ganze latte an tricks einfallen lassen musst, damit die sachen korrekt gerastert werden.
der vermutliche grund für den unterschied zwischen den GCN chips und den maxwell / pascal chips bzgl. dem TBR dürfte darin liegen, dass nvidia das von seiten der software über den treiber macht und amd das ganze in hardware gegossen hat.
nvidias ansatz ist im prinzip flexibler, hat aber die beiden nachteile, dass es a) nur für die pixel operationen funktioniert, compute und co dafür aber absäuft und b) für so ziemlich alles, nen neuer treiber her muss, der nen scheduling profil dafür mitbringt, damit das ganze überhaupt genutzt werden kann.
amds ansatz das ganze in hardware zu lösen ist im prinzip etwas starrer, da du kein micro management der sachen machen kannst, dafür passiert es nahezu automatisch. das problem hier ist aber, dass die schaltungen dafür recht viel strom fressen, weil die sehr viele informationen in sehr sehr kurzer zeit crunchen müssen.
der grosse vorteil ist, dass sich die gpu als solches komplett dynamisch den workloads anpassen kann. das ist das, woraus deren grosser async-compute vorteil geboren wurde.
btw. den hardware scheduler, der da durchaus einiges an strom schluckt war bis zur 600er serie ebenfalls bei nvidia vorhanden, nur war der dort sehr viel strom hungriger als der aktuelle bei amd.
effektiv haben die beiden firmen diesen ansatz getauscht. das was nvidia damals hatte hat amd jetzt in besser in benutzung und das was amd damals hatte macht nvidia jetzt.
|
|
|
|
|
|
|
|
|
|
|
Ich kann keinen längeren Beitrag von dir mehr lesen ohne mich zu fragen ob du dabei auf dem Klo saßt 
|
|
|
|
|
|
|
|
|
|
|
|
Dito
|
|
|
|
|
|
|
|
|
|
|
|
Ich les die zumindest immer am Klo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Naja, sie ist gut in dem wofür sie verkauft wird im Vergleich zur Fury, bin dann gespannt ob sich das mit dem Gaming wirklich bewahrheitet.
|
|
|
|
|
|
|
|
|
|
|
|
WTFTech hat einen 3DMark-Score der RX Vega ausgegraben, ordnet sich zwischen 1080 und 1080 Ti ein.
|
|
|
|
|
|
|
|
| Thema: Der Grafikkarten-Thread ( Jahr 2010 Edition mit Evergreen und Fermi ) |
