Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsAMD Radeon: Hinweise auf Dual-Fiji-GPU und „Polaris“ im Dezember
Achso, also mit anderen Worten: Man weiß es nicht.
Habe mal gegoogelt und auf deren Seite gesucht aber _auf die schnelle_ nichts konkretes darüber gefunden was genau und vor allem wie "vermessen" wurde.
Und was man mit "Black + Radom texture" über die Qualität einer Texturkompression aussagen möchte, verstehe ich auch nicht wirklich.
Vielleicht an den "urposter": Was wurde dort wie gemessen?
Auch wenn die 295X2 nur 430 W statt 500 W verbraucht sind das immer noch nicht die spezifischen 375 W (150 W + 150 W + 75 W). Das hat auch noch nicht mal was mit NV-Fanboy zu tun. NV hat ganz andere Probleme. Ich finde es einfach nicht angebracht ab Werk außerhalb der Spezifikationen zu arbeiten. Vorallem wenn es um Spannungsversorgung geht!
"Up to 28 A" für einen 8-Pin? Soll man das so verstehen? 12*28 = 336 W, hat mit Spezifikation nichts mehr zu tun... Wie der User das Ding betreibt ist ja an sich völlig egal, aber der Hersteller sollte sich schon dran halten.
Allein wegen den 970 Debakel werde ich mir so einen Karte nicht kaufen. Auch wenn sie noch so pretty nice and shiny ist.
Aber das ist nur die Meinung eines Einzelnen. Die dual Fiji hat auf jeden Fall das Zeug um super zu werden.
@ janeeisklar
Bei derjenigen Texturkompression, die das Benchmark untersuchen will, handelt es sich um eine verlustfreie Kompression. Verlustfreie Kompressionen suchen nach Mustern oder Regelmäßigkeiten in den zu komprimierenden Daten und stellen diese platzsparend da. Dementsprechen lassen sich regelmäßige Texturen besonders gut komprimieren. Zufällige Texturen hingegen sehr schlecht.
Zum Besipiel besteht eine schwarze Textur mit der Auflösung von 1024 auf 1024 Pixeln (1 Mibyte) nur aus einer langen Folge von 1024*1024 nullen. Eine verlustfreie Kompression könnte diese Regelmäßigkeit erkennen und die Textur effizent als 1 048 576 mal das Zeichen 0 abspeichern, was wiederum nur wenige Bytes wären. (Im Speziellen war dies eben die Run-Length-Enkodierungsmethode - es gibt noch ein paar andere verlustfreie Kompressionsmethoden die aber größtenteils recht ähnlich funktionieren)
Eine Random-Texture besteht aber wie der Namen vermuten lässt aus einer zufälligen Folge 0en und 1en. In dieser Folge existieren weder Regelmäßigkeiten noch Muster, die eine verlustfreie Kompression erkennen und platzsparend darstellen könnte. Deswegen lässt sich auch eine Random-Texture durch verlustfreie Kompression nicht komprimieren.
Dementsprechend verwendet das Benchmark einen Fall, wo die Texturkompression optimal funktioniert (schwarze Textur) und einen Fall wo die Texturkompression gar nicht funktioniert (random Texture) um eben einen Worst-Case und einen Best-Case zu benchmarken.
Was das Benchmark allerdings genau macht ist etwas fraglich. Sie schreiben hier etwas von einer eventuellen und ungewollten ROP-Limitierung im Benchmark, also scheint das Benchmark in einem Draw-Call und nicht bei einem Compute-Kernel aus einer solchen Textur zu lesen(?). Was genau das Benchmark macht konnte ich trotz google nicht finden - evtl hat jemand ja einen Link.
