amd versuchte den treiber so auch unter dx12 zertifizieren zu wollen. scheint nicht geklappt zu haben. er soll microsoft mehrere monate vorgelegen haben. dort konnte man lesen, in progress. man hatte ihn also eingereicht. man kann nur annehmen das microsoft hätte amd bevorzugen müssen und das macht man dort nicht. man muss sich an api vorgaben halten. alles andere ist wie gameworks was internes. als amd mitteilte das sie den allgemeinen pfad aufgeben war der eintrag dann bei microsoft verschwunden. wird amd wohl ein eigenes softwarebackend unter dx12 brauchen und das kollidiert mit ihrem grundgedanken open source.
Nein - darum ging es überhaupt nicht. Warum sollte Microsoft AMD etwas verwehren das ein Hardwarenahes Feature sein kann und durch DX12 unterstützt werden könnte (das ist ja nichts weiter als eine Sammlung), wenn nicht als allgemeines Feature, dann eben als spezielles nur für AMD. Das ist überhaupt kein Problem.
Es ging darum das der allgemeine Treiberstack den Entwicklern die Arbeit stark erleichtert hätte. Sie hätten den NGG Path so nur einmal ansprechen müssen und der Treiber hätte den Rest erledigt. Der Aufwand beim Entwickler wäre drastisch gesunken und das war auch Koduris Absicht, mehr auf die Entwickler eingehen und ihnen zu helfen. Softwareressourcen finden und freisetzen. Nur ist das nicht so einfach wie es erscheint, Enginesupport inbegriffen.
Der NGG Path und damit die Primitive Shader sind durch Entwickler über APIs ansprechbar, genauso wie FP16 und DSBR (directX). Nur bringt es ohne den Treiber erheblichen Programmierungsaufwand mit sich, worauf die Entwickler aus zeitlichen Gründen zu oft verzichten. Ohne optimierte Treiber werden die Ergebnisse wegen der komplexen Schnittstelle dann zu durchwachsen ausfallen, denn die Entwickler sind auf sich allein gestellt. Schon unter DX12 hängt es davon ab, was der Entwickler wirklich leisten kann und er auf Tasche hat.
Unter Linux Kernel und GPUopen (source wie amdvlk) wird NGG derzeit durch gfx9 noch nicht unterstützt, dass soll mit gfx10 (Navi) behoben werden. Möglich sind dann auch Erleichterungen durch den Treibersupport, den AMD dann erneut in Angriff nehmen will.
Zur Erläuterung: Koduri verzichtete bei Vega auf das "Aufbohren" der Rasterengine in Hardware - trotz hoher Shaderanzahl. Man hielt an den 4 Rasterengines fest (Fiji), was wahrscheinlich auch eine Vorgabe durch AMD war, um die Kosten bei der Entwicklung und Produktion zu senken. Die 4 Engines ergeben einen Output von 4 Primitives pro Takt und könnten im Zusammenspiel mit NGG auf max 17 Primitive gesteigert werden.
Das dies bei Vega20 geändert wurde glaube ich nicht. Der Chip wird wenn er für Consumer kommt, eher von der 7nm Effizienz profitieren können und wie gesagt können Entwickler die hardwarenahen Feature ansprechen. Es machen nur weniger oder keiner davon Gebrauch, weil es sehr komplex ist - man dann Aufwand und Nutzen gegenüber stellt.
Ich glaube an eine Vega20 FE. Die wird mehr kosten als 600$, ich würde von 900-1200 ausgehen.
Die TDP für Vega20 liegt bei MAXIMAL 300Watt = nicht allgemein 300Watt.