Also ich weis nicht was alle immer mit dem dx12 haben.Ich sehe darin keine zukunft.Ist einfach zu viel mehraufwand für die Entwickler.Und optisch sehe ich da auch kein Vorteil.Nun weis ich auch warum Nvida nicht auf diesem Zug aufgesprungen ist.AMD hätte optinonal ein dynamische auslastung einbauen sollen,der sowohl bei dx11 als auch bei dx12 hilft und nicht nur dx12.Dann wäre auch jetzt AMD auch noch besser dran als jetzt.
Dann hat er ja Recht: NVIDIA bekommt das ja durchaus hin, DX11 auch mehrkernig zu gestalten und ihre Grafikkarten besser auszulasten. Somit versucht AMD nur mit DX12 ihre eigene Arbeit auf die Entwickler zu verschieben. Ob das so sinnvoll ist, ist fraglich.Das liegt wahrscheinlich aber schlicht und einfach daran das du ohne dir böse zu wollen wenig Ahnung zu der Thematik hast. Mit DX11 ist man nicht in der Lage die Hardware so direkt anzusprechen wie es mit DX12 möglich ist dadurch ist es schlicht nicht möglich Prozesse auf viele Kerne zu parallelisieren sprich man kann nicht so viele Kerne vernünftig auslasten. Auch Grafikkarten deren Architektur vereinfacht gesagt auf mehr "Kerne" anstatt Takt setzen sind mit DX11 nicht gut auszulasten was man deutlich in der Vergangenheit an der Fury gesehen hat bzw. jetzt eben an der Vega sieht.
Dann sollte AMD vielleicht einfach mal eine neue Architektur entwickeln....?Grundsätzlich ist das so allerdings Architektur bedingt, AMD hat mit GCN einfach eine Architektur die relativ schwierig auszulasten ist sobald der Chip groß wird weil sie eben nicht auf einen unglaublich hohen Takt gebaut ist.
Nein, eben nicht. Die Programmierung wird deutlich schwieriger und aufwändiger, weil näher an der Hardware auch bedeutet, mehr Aufwand treiben zu müssen, den früher DX11 übernommen hat. AMD verlagert hier einfach nur Arbeit von ihren Treiberentwicklern auf die Spieleentwickler. Das ist alles. "einfach" ist daran nichts. Siehe auch die ganzen vermurksten DX12-Ports. Nicht mal DICE kriegt das gut hin.DX12 bietet hier einfach die Möglichkeit (wenn gut implementiert) die Hardware besser auszulasten da man näher an der Hardware optimieren kann.
... Doom mit Vulkan hat denke ich sehr eindrucksvoll gezeigt was möglich ist und wohin es geht.
Du hast es als "einfach" bezeichnet. Für mich bedeutet einfach, dass es eben einfacher ist, also weniger Aufwand (und Erfahrung, Kenntnisse etc. pp.) benötigt.Nirgendwo habe ich geschrieben das man auf DX12 nicht mehr Aufwand verlangt
DX11 ist sicherlich nicht die Zukunft, aber eben die Gegenwart. Für die nächsten Jahre. Und das wird auch so bleiben, einfach, weil LowLevel APIs hoch komplex sind und für >90% der Entwicklungsstudios einfach nicht leistbar sind. Dafür fehlt schlicht die ManPower.Grundsätzlich muss es eben mal weiter gehen sonst stagniert der Markt wieder und das gefällt niemand und eine 7 alte API kann eben nicht die Zukunft sein.
Fraglich, ob ein Spiel, dass explizit mit dem Label eines IHVs wirbt, nun das große Beispiel für LL-APIs ist. Komisch - bei GameWorks wurde das immer kritisiert, wenn ein Spiel sich zu sehr einem IHV unterwirft, bei Doom wird es beklatscht und ständig als Beispiel genutzt. Verstehe ich nicht.Doom mit Vulkan hat denke ich sehr eindrucksvoll gezeigt was möglich ist und wohin es geht.
Dann erkläre doch mal, was du mit "einfach" meinst. Offensichtlich hast du nicht "einfach" gemeint, sondern - ja, was denn genau?Das einfach kannst du auch durch grundsätzlich oder runter rationiert ersetzen bitte nicht einfach Wört aus dem Kontext nehmen..
DOOM(R) | AMDWas bitte ist ein IHVs? Vulkan ist eine offene, Plattform übergreifende Schnittstelle warum sollte man Doom nicht als Beispiel nehmen wenn es da einfach gut umgesetzt ist?
DX12 bietet hier grundsätzlich die Möglichkeit (wenn gut implementiert) die Hardware besser auszulasten da man näher an der Hardware optimieren kann.
DX12 bietet hier rationiert die Möglichkeit (wenn gut implementiert) die Hardware besser auszulasten da man näher an der Hardware optimieren kann.
OpenGL, ein offener Standard für die plattform- und programmiersprachenübergreifende 3D-Grafik-Entwicklung.