Seite 17 von 17 ... 71314151617
  1. #161
    Avatar von Gimmick
    Mitglied seit
    06.04.2009
    Beiträge
    1.842

    AW: AMD-Manager spricht über Konkurrenzkampf mit Intel: "Wir haben jetzt ein Jahr Vorsprung"

    Zitat Zitat von gaussmath Beitrag anzeigen
    Mir kann allerdings keiner erzählen, dass man mit Entwicklungskosten eines AAA Titels im dreistelligen Milionenbereich keine LL API vorsehen kann.
    Jeder Softwarehersteller, der sich die grafische und technologische Führungsposition auf die Fahne schreiben will, wird auf DX12/Vulkan umsteigen. Haben ja auch garkeine andere Wahl.
    Bin jedenfalls mal gespannt, wann man was zu AnvilNext Engine mit DX12 hört, bei AC: Odyssey stand wohl mal kurz DX12 als Mindestanforderung drin. Entweder ein Omen, dass DX12 enthalten sein wird - oder nur ein Tippfehler

    •   Alt

      Anzeige
      Bitte einloggen, um diese Anzeige auszublenden.
       

  2. #162
    Avatar von gaussmath
    Mitglied seit
    27.09.2007
    Beiträge
    2.430

    AW: AMD-Manager spricht über Konkurrenzkampf mit Intel: "Wir haben jetzt ein Jahr Vorsprung"

    Zitat Zitat von lutari Beitrag anzeigen
    Die 10nm-Fertigung von Intel ist aktuell technisch geschätzt ca. 2 Jahre der 7nm-Fertigung von TSMC im Vorteil.
    Inwiefern? Mein letzter Stand war, dass die beiden Verfahren ziemlich ähnlich sind, zumindest, was die realen Maße der Einheiten betrifft.

    Zitat Zitat von Gimmick Beitrag anzeigen
    Jeder Softwarehersteller, der sich die grafische und technologische Führungsposition auf die Fahne schreiben will, wird auf DX12/Vulkan umsteigen. Haben ja auch garkeine andere Wahl.
    Hoffentlich. Es wirken allerdings auch sehr viele "Kräfte" dagegen: die Entwicklungskosten, viele Leute nutzen immer noch Windows 7, die Entwicklungskosten, Nvidias Hohheit bei DirectX 11, die Entwicklungskosten...

    Wie ist eigentlich die Abdeckung von Entwicklern mit LL API Know-How auf dem Arbeitsmarkt?
    Geändert von gaussmath (17.06.2018 um 09:03 Uhr)
    Nobody ever got fired for buying Xeon.
    Until now.

  3. #163
    Avatar von Locuza
    Mitglied seit
    30.10.2009
    Ort
    BW
    Beiträge
    10.515

    AW: AMD-Manager spricht über Konkurrenzkampf mit Intel: "Wir haben jetzt ein Jahr Vorsprung"

    Zitat Zitat von Casurin Beitrag anzeigen
    Da kommt es mir vor als würde der erste Satz davon eher auf dich zutreffen.
    LowLeverl Apis sind genau das gegenteil von Platform unabhängig - es muss genau auf die hardware abgestimmt wwerden oder es läuft garnicht - was es sogar schon schwer macht den Code sowohl auf AMD, Intel und Nvidia GPUs laufen zu lassen - es sei den man beschränkt sich auf den Grundbefhelsatz womit dann auch die Vorteile nicht genutzt werden. Es gibt einen grund warum man von den früheren low-level APIs und Sprachen weggegangen ist: weil es ein derartig großer Aufwand ist.
    Mit den highlevel APIs hat man auch einen entsprechend Umfangreichen und mächtigen Treiber der viele Aufgaben übernimmt und vom GPU Hersteller und nur diesem allein gewartet werden muss. Und da setzt dann AMD an - sie wollen mehr open Source und lowlevel APIs sehen denn das bedeutet das die Veranwortung nichtmehr bei ihnen liegt - sie müssenen keine komplexen Treiber mehr erstellen.

    Eine kleine Grafik anzeigen ist mit allen Apis eigentlich elicht wenn man ein Framework hat.
    Will ich die vorteile meiner AMD Karte nutzen muss ich mich schon mehr mit den APIs auseinander setzen. Will ich Vulkan nutzen heist das ich muss das ganez Speicher Managment, Texturverwaltung und so weiter.
    Mit lowlevel APIs muss dann der Programierer sich um sachen wie die CommandQueues selber kümmern. Da kommt man dann schnell auf Probleme wie zB das auf einer Architectur das erstellen von MipMaps in eine Queue erfolgen muss, in einer anderen kann es aufgeteilt werden.
    Zu wissen welche Architektur jetzt was macht/kann/benötigt fällt nunmehr dem programmierer zu. Für jede Engine muss dies dann seperat gemacht werden.
    Dezeit wenn eine neue Architektur heraus kommt wird vom Hersteller ein entsprechend angepasster neuer Treiber released der dann die neue ahrdware auch für ältere Spiele nutzen kann.
    lowLevel? Ja viel Spaß - wenn man nciht schon im vorhinein die nächste hardware kennt kann man sie auch nicht ausnützen. Um dann von neuen Features zu profitieren (zB delta color compression, hardware accelerated trilinear filtering etc) muss dann das Spiel gepached werden.

    Und da sieht man dann schnell warum das Aufwendig ist:
    AMD/Intel/Nivdia haben duzende Programierer die nur daran arbeiten die Treiber aktuell zu halten und neue Hardwarefeatures zu nutzen. Ein Team für einen Hersteller.
    Wenn die das ncihtmehr machen - wer dann? Ja - 1 Team pro ENGINE. Schlimmer ncoh wenn man dann ncoh angepasste Engines oder Hauseigen hat.
    Wenn man sich an die DX12 Spec hält, läuft der Code prinzipiell auf jeder Hardware, wie es der Theorie nach immer funktioniert und neue Hardware braucht entweder explizite Unterstützung für neue Feautures wie bei jeder API oder setzt das transparent hinter der API um, was mehrheitlich unter DX12 genauso funktioniert, wie unter DX11, da die ganzen Ressourcen, Buffer-Typen und Shader im Prinzip gleich funktionieren und abstrahiert sind.
    Man arbeitet mit fetten PSOs, der Shader-Sprache und das ist alles nicht hardware spezifisch standardiziert und muss vom IHV Treiber und nicht dem Programmierer selber explizit für die Hardware übersetzt werden.

    Die Vergleiche mit der Vergangenheit sind auch sehr krude.
    Die Situation früher war wie im wilden Westen, es gab stark unterschiedliche APIs, keine abstrahierte Shader-Sprache wie HLSL/GLSL, sondern Shader Assembly Code, es gab viele Treiberbugs, unsaubere Spezifikationen, schlechte Conformance zum Standard, keine oder miese Tools für Entwickler etc.
    Was man jetzt als "low-level" bezeichnet oder coding to the metal ist arg unterschiedlich, zudem was um die Jahrtausendwende getan wurde.

    Aber DX12/Vulkan sind in ihrer Rohform natürlich keine APIs für schnelles und einfaches Programmieren, es sind explizite High-Performance APIs für Anwendungen die an die Grenzen von bisherigen APIs stoßen.
    Auf der anderen Seite gibt es aber viele Bemühungen, dass ganze für Einsteiger und andere Anwendungsbereiche einfacher zu machen.
    AMD bietet einen genrischen Memory-Allocator für Vulkan an, man muss sich dann nicht damit herumschlagen selber einen zu schreiben, sogar einen fett abstrahierten Layer mit Vulkan-EZ bietet AMD an, der die Programmierung ziemlich ähnlich gestaltet wie unter DX11/OGL:
    V-EZ brings “Easy Mode” to Vulkan - GPUOpen

    Das Feature DCC funktioniert übrigens transparent, die Hardware verwendet das Feature bei AMD, je nachdem ob die Anwendung für ihr Rendertarget ein UAV flag gesetzt hat oder nicht, die Geschichte unterscheidet unter DX11 und DX12 nicht voneinander.
    AF kann Nvidias Treiber nach wie vor unter DX12 erzwingen, genauso wie höhere Auflösungen (DSR), FXAA, LOD-Bias etc..

    Zitat Zitat von Gimmick Beitrag anzeigen
    Jeder Softwarehersteller, der sich die grafische und technologische Führungsposition auf die Fahne schreiben will, wird auf DX12/Vulkan umsteigen. Haben ja auch garkeine andere Wahl.
    Bin jedenfalls mal gespannt, wann man was zu AnvilNext Engine mit DX12 hört, bei AC: Odyssey stand wohl mal kurz DX12 als Mindestanforderung drin. Entweder ein Omen, dass DX12 enthalten sein wird - oder nur ein Tippfehler
    Präsentiert hat es Ubisoft schon letztes Jahr:
    http://32ipi028l5q82yhj72224m8j.wpen...ns-Learned.pdf

    Ob es endlich mit AC: Odyssey Einzug erhält?
    The Division 2 hatte den gleichen Platzhalter, DX12 als Min und empfohlene Spec.

    Sehr wahrscheinlich haben aber beide Spiele noch DX11-Support, The Division 2 sehr wahrscheinlich DX12, weil schon das erste Spiel besaß DX12-Support nach einem Patch und AMD kooperiert bei dem Spiel mit Ubisoft.
    Wäre aber schon interessant zu wissen, ob AC auch DX12 implementiert.


    Zitat Zitat von gaussmath Beitrag anzeigen
    Inwiefern? Mein letzter Stand war, dass die beiden Verfahren ziemlich ähnlich sind, zumindest, was die realen Maße der Einheiten betrifft.

    Hoffentlich. Es wirken allerdings auch sehr viele "Kräfte" dagegen: die Entwicklungskosten, viele Leute nutzen immer noch Windows 7, die Entwicklungskosten, Nvidias Hohheit bei DirectX 11, die Entwicklungskosten...

    Wie ist eigentlich die Abdeckung von Entwicklern mit LL API Know-How auf dem Arbeitsmarkt?
    Zwei Artikel die es ausführlich darlegen:
    IEDM 2017 + ISSCC 2018: Intel’s 10nm, switching to cobalt interconnects – WikiChip Fuse
    IEDM 2017: GlobalFoundries 7nm process; Cobalt, EUV – WikiChip Fuse

    Geht es nach Intels MTr/mm²-Metrik, welche verschiedene Eigenschaften eines Prozesses unterschiedlich gewichtet, dann hat Intel eine ~20% höhere Dichte als der 7nm Prozess bei GloFo.
    TSMC hat einen etwas kleineren Contacted Gate Pitch als Glofo (54nm vs. 56nm), gibt aber praktisch die gleiche Größe für eine SRAM-Zelle wie GloFo an, deren Prozesse sollten nah beieinander liegen.

    Intel erreicht nicht so Dichte SRAM-Zellen wie die Konkurrenz, aber deren Metalverbindungen sind kleiner, als bei der Konkurrenz und Intel kann die Transistoren dichter gruppieren, dank Contact-Over-Gate, was die Konkurrenz erst später selber verwenden möchte.
    Ich weiß jetzt nicht, ob Intel auch als einziger Single-Dummy-Gates verwenden wird.
    Intel wird wahrscheinlich auch noch Vorteile bei der Schaltgeschwindigkeit der Transistoren haben.

    Aber Intels 10nm Prozess könnte erst 1 Jahr nachdem 7nm TSMC Prozess als High-Volume-Prozess zum Einsatz kommen und auch nachdem Release sollte Intels Vorsprung relativ kleiner ausfallen, als er aktuell ist.

    --------

    Bezüglich APIs würde ich generalisiert einfach die Zeit als größten Limiter ansehen.
    Zwei bis drei Komponenten sind der größte Bremsfaktor.
    1. Windows 7, wären alle bei W10 würde die Sache mittelfristig anders aussehen.
    2 und 3 praktisch, die nötigen Engine-Anpassungen dauern mehrere Jahre, die Spieleentwicklung selber dauert auch mehrere Jahre und nicht immer sind Engine-Entwicklungen synchron mit Spieleentwicklungen.
    Manchmal kann es einen viel moderneren Engine-Branch geben, aber die Spiele welche schon 2-3 Jahre in Entwicklung sind, können da nicht einfach wechseln und setzen erst auf die nächste Kadenz, dass kann dann dazu führen, dass Spiele mit guter API-Umsetzung dann 4-6 Jahre entfernt sind.
    Geändert von Locuza (17.06.2018 um 09:25 Uhr)

  4. #164
    Avatar von Gimmick
    Mitglied seit
    06.04.2009
    Beiträge
    1.842

    AW: AMD-Manager spricht über Konkurrenzkampf mit Intel: "Wir haben jetzt ein Jahr Vorsprung"

    Zitat Zitat von gaussmath Beitrag anzeigen
    Hoffentlich. Es wirken allerdings auch sehr viele "Kräfte" dagegen: die Entwicklungskosten, viele Leute nutzen immer noch Windows 7, die Entwicklungskosten, Nvidias Hohheit bei DirectX 11, die Entwicklungskosten...
    Vulkan läuft auch auf WIndows 7 ^^.

    Zitat Zitat von Locuza Beitrag anzeigen

    Präsentiert hat es Ubisoft schon letztes Jahr:
    http://32ipi028l5q82yhj72224m8j.wpen...ns-Learned.pdf

    Ob es endlich mit AC: Odyssey Einzug erhält?
    The Division 2 hatte den gleichen Platzhalter, DX12 als Min und empfohlene Spec.

    Sehr wahrscheinlich haben aber beide Spiele noch DX11-Support, The Division 2 sehr wahrscheinlich DX12, weil schon das erste Spiel besaß DX12-Support nach einem Patch und AMD kooperiert bei dem Spiel mit Ubisoft.
    Wäre aber schon interessant zu wissen, ob AC auch DX12 implementiert.
    Wäre wünschenswert ^^.

  5. #165
    Avatar von Locuza
    Mitglied seit
    30.10.2009
    Ort
    BW
    Beiträge
    10.515

    AW: AMD-Manager spricht über Konkurrenzkampf mit Intel: "Wir haben jetzt ein Jahr Vorsprung"

    Für Vulkan spricht wirtschaftlich einfach nicht viel.
    Zu 99% kommt der Umsatz von Windows und da viele Studios einen technischen Übergang machen, wird einfach DX11 für die älteren Systeme verwendet.
    Vulkan ist nur attraktiv, wenn die Engine schon wirklich soweit um von den neuen APIs zu profitieren und man DX11 ganz ersetzen möchte, auch für W7-Kunden oder eben in der Linux-Nische wildern möchte.
    Aber Windows 7 will man im Prinzip nicht unterstützen, außer es gibt eine persönliche Abneigung gegenüber Windows 10 bzw. wird dazu wirtschaftlich einfach gezwungen.
    Das OS ist verdammt alt und hat eine alte Treiberinfrastruktur mit WDDM1.1, welche zu Problemen führt.

    Am liebsten würden die IHVs nur W10-Treiber schreiben, dann muss man nicht unterschiedliche Treibermodelle pflegen und entwickeln und viele ISVs ebenso, weniger OS-Management, weniger unterschiedliche Verhaltensweisen und spezifisches Profiling.

  6. #166
    Avatar von yummycandy
    Mitglied seit
    02.07.2016
    Liest
    PCGH.de & Heft
    Ort
    Ankh-Morpork
    Beiträge
    979

    AW: AMD-Manager spricht über Konkurrenzkampf mit Intel: "Wir haben jetzt ein Jahr Vorsprung"

    Zitat Zitat von Locuza Beitrag anzeigen
    Aber Intels 10nm Prozess könnte erst 1 Jahr nachdem 7nm TSMC Prozess als High-Volume-Prozess zum Einsatz kommen und auch nachdem Release sollte Intels Vorsprung relativ kleiner ausfallen, als er aktuell ist.
    Intels Problem soll angeblich nicht nur in den Cobalt Isolatoren liegen, sondern auch in der genrellen Realisierung. Wobei die Frage ist, ob sie nicht auch nur ASML-Maschienen einsetzen?

    Ansonsten sind die Prozesse, abseits der Dichte, wirklich vergleichbar, wobei noch erwähnt werden muß, daß die Kosten pro Die nicht wirklich geringer sind, als bei 14nm. Schon allein aufgrund der gestiegenen Forschungs- und Maschienenkosten.

    Edit: So richtig spannend wirds erst mit EUV. Wobei noch nicht raus ist, ob Intel auch auf EUV geht mit 10nm+.
    FX8320 | Macho HR02 | 32GB | 270x | 500GB 850EVO | 10TB HD | Zyxel NAS 542 8TB | Nanoxia DS2 | VN279QL (AMVA+) | Xonar DGX | CM Sentinel III | Logitech G710+ | Logitech G933 | Teufel Concept E 400
    ----
    http://www.sysprofile.de/id183798

Seite 17 von 17 ... 71314151617

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •