1. Foren
  2. Kommentare
  3. Wissenschaft
  4. Alle Kommentare zum Artikel
  5. › Grafikchips und Prozessoren: 2016…

HBM

  1. Thema

Neues Thema Ansicht wechseln


  1. HBM

    Autor: Chris0706 17.07.15 - 16:27

    Der High Bandwidth Memory auf der Fury X war dann anscheinend nur eine lapidare Neuerung ...

  2. Re: HBM

    Autor: ms (Golem.de) 17.07.15 - 16:32

    Der HBM hat nicht direkt etwas mit dem Fertigungsprozess zu tun, weswegen ich ihn hier nicht erwähnt habe. HBM hat AMD freilich geholfen mehr ALUs in den Fiji-Chip zu packen, Nvidias GM200 aber zeigt, dass man mit GDDR5 ähnlich viel Leistung herausholen kann (gleicher Prozess und ähnlicher Die-Size).

    Marc Sauter, Sr Editor
    Golem.de

  3. Re: HBM

    Autor: spiderbit 17.07.15 - 16:53

    Nur schafft es AMD leicht in 4k an Nvidia vorbei zu ziehen oder gleich auf zu bleiben wie mans sieht mit Fiji aus 2011 wo Keppler von 2014 ist, also da hat HBM mal 3 Jahre Architektur Unterschied aus geglichen. Das kommt schon einem Shrink nahe.

  4. Re: HBM

    Autor: ms (Golem.de) 17.07.15 - 17:03

    Weder ist die Architektur in Fiji von 2011 (sondern GNC v3 von 2014) noch steckt im GM200 die Kepler-Architektur, sondern Maxwell.

    Marc Sauter, Sr Editor
    Golem.de

  5. Re: HBM

    Autor: derats 17.07.15 - 17:29

    ms (Golem.de) schrieb:
    --------------------------------------------------------------------------------
    > Weder ist die Architektur in Fiji von 2011 (sondern GNC v3 von 2014) noch
    > steckt im GM200 die Kepler-Architektur, sondern Maxwell.

    Außerdem hat AMD immer noch große Probleme - trotz HBM - die Rohrechenleistung auf die Straße zu bringen. Durchdrehende Reifen bringen einen nicht über die Ziellinie...

  6. Re: HBM

    Autor: JTR 17.07.15 - 17:41

    Ja vor allem sind 35 bis 40 FPS bei 40K immer noch zu wenig und bei den anderen Auflösungen sind sie bestenfalls gleich auf mit Nvidia. Und Wasserkühlung will auch nicht jeder in seinem Rechner haben. Gerade die Fury X ist ein Nischenprodukt.

  7. Re: HBM

    Autor: Ext3h 17.07.15 - 19:09

    derats schrieb:
    --------------------------------------------------------------------------------
    > ms (Golem.de) schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Weder ist die Architektur in Fiji von 2011 (sondern GNC v3 von 2014)
    > noch
    > > steckt im GM200 die Kepler-Architektur, sondern Maxwell.
    >
    > Außerdem hat AMD immer noch große Probleme - trotz HBM - die
    > Rohrechenleistung auf die Straße zu bringen. Durchdrehende Reifen bringen
    > einen nicht über die Ziellinie...

    Geringe Probleme bei der Geometrie-Leistung, das ist noch der Hardware geschuldet. Und die Architektur ist nach dem Umstieg von einer primär auf Double-Precision ausgerichteten Shaderarchitektur auf Single-Precision auch noch nicht ganz so effizient wie das eigentlich möglich wäre, das sollte sich aber noch geben. Immerhin hat bei dem letzteren Punkt Nvidia jetzt mittlerweile fast 5 Jahre mehr Erfahrung.

    Hauptproblem ist aber nicht die Hardware, sondern die Software. DirectX ist einfach eine beschissene Schnittstelle die bereits über Jahre hinweg an den Fähigkeiten der Hardware vorbei entwickelt wurde.

    Diese immense Vergeudung von Rechenleistung die man mit DX11 hat, gehören einfach der Vergangenheit an. Da hat Nvidia in den letzten Jahren die Standards bis zum brechen gebogen um da noch das letzte bisschen Performance für zusätzliche Render- und Drawcalls auf einer nur sequentiell ansprechbaren Schnittstelle raus zu quetschen, aber damit ist jetzt Schluss.

    Mit Vulkan/DX12 sind beide Hersteller erst mal wieder WEIT davon entfernt, in der Praxis irgendwie durch die Treiber-Performance limitiert zu sein. Positiv für beide Hersteller, denn das bedeutet dass wieder mehr Ressourcen in die Verbesserung der Hardware und Entwicklung neuer Frameworks fließen können.

    Was wir aktuell sehen, gerade bei niedrigeren Auflösungen, ist mit Verlaub gesagt schon lange nicht mehr die Leistungsfähigkeit der Grafikkarte sondern die des Treibers, und Energieeffizienz misst sich dabei auch nicht darin wie effizient die Architektur tatsächlich ist sondern nur wie schnell sie runter taktet während sie auf den Treiber wartet.



    1 mal bearbeitet, zuletzt am 17.07.15 19:14 durch Ext3h.

  8. Re: HBM

    Autor: Moe479 17.07.15 - 19:25

    warum drücken dann beide nicht konsequent, zusammen mit intel gegen ms eine vernüpftige schnittstelle gemeinsam durch, z.b. indem sie drohen das linuxlager mit offenlegung dieser zu befeuern? ich mein ms hat mit dx12 nur mit hängen und würgen eingelenkt ... und in nen paar jahren steht man erneut vor exakt dem gleichen problem und muss demonstrationsprojekte wie mantel metal oder vulkan forcieren um das potetial, bei der hardware der kundschaft auszuschöpfen!

    aber vermutlich leidet man unter entsetzlicher abgrenzungsnot und baut deswegen ganz grundsätzlich andere geräte als die sowieso schlechteren mitbewerber, so dass man keine übereinstimmungen finden kann ...



    4 mal bearbeitet, zuletzt am 17.07.15 19:38 durch Moe479.

  9. Re: HBM

    Autor: Ext3h 17.07.15 - 20:48

    Moe479 schrieb:
    --------------------------------------------------------------------------------
    > warum drücken dann beide nicht konsequent, zusammen mit intel gegen ms eine
    > vernüpftige schnittstelle gemeinsam durch, z.b. indem sie drohen das
    > linuxlager mit offenlegung dieser zu befeuern?

    Rate doch mal was Vulkan (aka OpenGL Next) ist. Das ist AMDs Mantle-Schnittstelle (nur umbenannt und ergänzt), und wird von allen 3 GPU-Herstellern + Konsolenherstellern in Kooperation entwickelt. Linux-Support ist ebenfalls bereits in Arbeit.

    DX12 ist auch nicht schlecht - im Endeffekt ist es Microsofts Versuch auf Krampf eine Schnittstelle nach dem Vorbild von AMDs Mantle zu entwickeln um Vulkan auf der Windows-Platform so lange es geht in Schach zu halten. Funktioniert im Endeffekt in vielen Teilen identisch mit Vulkan, ist genauso schlank, und hat mit DX9/10/11 fast überhaupt nichts mehr zu tun.

    Lustiger Fakt: Linux lernt mittlerweile ebenfalls nativ DirectX (die älteren Versionen) direkt auszuführen, ohne Zwischenschicht wie Wine. (Wine is not an emulator - das Teil hat bislang einfach DirectX 1:1 in OpenGL übersetzt.)



    1 mal bearbeitet, zuletzt am 17.07.15 20:50 durch Ext3h.

  10. Re: HBM

    Autor: Dr. WatsON 17.07.15 - 21:16

    Ext3h schrieb:
    --------------------------------------------------------------------------------
    > Lustiger Fakt: Linux lernt mittlerweile ebenfalls nativ DirectX (die
    > älteren Versionen) direkt auszuführen, ohne Zwischenschicht wie Wine. (Wine
    > is not an emulator - das Teil hat bislang einfach DirectX 1:1 in OpenGL
    > übersetzt.)

    Quelle? Erklärung?

  11. Re: HBM

    Autor: Ext3h 17.07.15 - 21:25

    Dr. WatsON schrieb:
    --------------------------------------------------------------------------------
    > Quelle? Erklärung?
    http://www.phoronix.com/scan.php?page=article&item=mesa_gallium3d_d3d11&num=1
    https://www.phoronix.com/scan.php?page=news_item&px=MTg2Mjc
    http://www.heise.de/open/meldung/Linux-Grafiktreiber-erhalten-Direct3D-9-Unterstuetzung-2459135.html

    Ist effektiv Grundlagenarbeit, notwendig da OpenGL und DirectX unterschiedliche Zustandsautomaten und Zugriffs-Reihenfolgen erfordern. DirectX auf OpenGL zu übersetzen und dann erst OpenGL auf die interne Architektur zu übersetzen ist in der Hinsicht teilweise "suboptimal" da einige Funktionsaufrufe erst mal komplett umsortiert werden müssen. Das spart man sich mit der Entwicklung.

    Langfristig sollte dass dazu führen, dass Projekte wie Wine noch zuverlässiger und schneller bei der "Entführung" von Programmen aus der Windows-Welt zu werden.

  12. Re: HBM

    Autor: derats 17.07.15 - 22:16

    Dr. WatsON schrieb:
    --------------------------------------------------------------------------------
    > Ext3h schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Lustiger Fakt: Linux lernt mittlerweile ebenfalls nativ DirectX (die
    > > älteren Versionen) direkt auszuführen, ohne Zwischenschicht wie Wine.
    > (Wine
    > > is not an emulator - das Teil hat bislang einfach DirectX 1:1 in OpenGL
    > > übersetzt.)
    >
    > Quelle? Erklärung?

    Gibt zwei oder drei Direct3D State Tracker für Gallium, einer wird aktuell entwickelt. Grob gesagt bilden State Tracker die API auf die zugehörige Zustandsmaschine ab und machen entsprechende Calls in Gallium um den Treiberzustand zu manipulieren, Batches zu erstellen etc.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. (Junior) IT-Anforderungsmanager (m/w/x) Warenwirtschaftssysteme / Filialhandel - International
    ALDI International Services GmbH & Co. oHG, Mülheim an der Ruhr
  2. Backend Entwickler TYPO3 (w/m/d)
    DMK E-BUSINESS GmbH, Chemnitz, Berlin-Potsdam, Köln
  3. IT Systemadministrator / Junior Projektleitung (m/w/d)
    DS Smith Packaging Deutschland Stiftung & Co. KG, Erlensee
  4. Senior Consultant Digitale Transformation (m/w/d)
    Mediaan Deutschland GmbH, Düsseldorf

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 569,99€
  2. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de