Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Mantle & Vulkan = Bezahlte AMD PR - wo nie etwas für den Endverbraucher bei rauskommt ?

=> siehe (BF4 Mantle VRAM Leak -Error) AMD blame Dice / Dice blame AMD

https://www.reddit.com/r/Battlefield_4_CTE/comments/2zlvbn/mantle_vram_leak_bug_stll_not_fixed/ / Memory leak in BF4 w page 61/64 - Forums - Battlelog / Battlefield Hardline

3dcenter geht übrigens davon aus dass Pascal keine ACEs beherrschen wird weil Pascal mehr oder wenige ein Shrink ist gegenüber Maxwell

Du beziehst Dich wie so viele auf veraltetet Aussagen von 3dcenter die längst bereits von 3dcenter selber widersprochen wurden - lies mal diesen Thread bis zum Ende... => http://extreme.pcgameshardware.de/n...-nm-finfet-ueber-tsmc-laufen-post7711808.html
 
Zuletzt bearbeitet:
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Ich kann schon mal eindeutig sagen, dass Mantle stellenweise stark verändert wurde.
Nur einen neuen Namen hat man darunter nicht geschrieben, hätte man ansonsten auch schon vor vielen Monaten machen können und herausbringen.
Das ist so unsinnig, Mantle und Vulkan immer gleichzusetzen.
Die technische Spezifikation unterscheidet sich, der Entwicklungsprozess unterscheidet sich, der Inhaber unterscheidet sich.
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

O.K., "basiert auf" ist zu viel des Guten

mir gings eher darum, dass scully es so darstellt als ob Mantle eine komplette Fehlentwicklung war welche jetzt absolut keine Bedeutung mehr hat

was ja nicht stimmt, da es teilweise in Vulkan weiter lebt

"What has changed from Mantle is that Khronos has gone through a period of refinement, keeping what worked in Vulkan and throwing out portions of Mantle that didn’t work well – particularly HLSL and anything that would prevent the API from being cross-vendor – replacing it with the other necessary/better functionality."

Next Generation OpenGL Becomes Vulkan: Additional Details Released
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Mantle & Vulkan = Bezahlte AMD PR - wo nie etwas für den Endverbraucher bei rauskommt ?

=> siehe (BF4 Mantle VRAM Leak -Error) AMD blame Dice / Dice blame AMD
Mantle und Vulkan sind beides technisch tolle APIs und Vulkan ist der größte Anwärter auf eine neutrale Zukunft von allen APIs.

Ein VRAM-Leak ist schließlich kein Grundbestandteil einer API.
Bei Battlefield 4, sollte man sich sowieso nicht wundern.

mir gings eher darum, dass scully es so darstellt als ob Mantle eine komplette Fehlentwicklung war welche jetzt absolut keine Bedeutung mehr hat
Mantle war und ist ein großartiger Kickstarter.
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Mantle und Vulkan sind beides technisch tolle APIs und Vulkan ist der größte Anwärter auf eine neutrale Zukunft von allen APIs.

"Vulkan ist der größte Anwärter auf eine neutrale Zukunft" - Ach ja... ?!? Wann denn - 2019 / 2022? Khronos Group - Initial release Late 2015 (expected) v.1.0

Mantle API ist tod & die Vulkan API ist noch nicht mal in der "Kinderstube" und steckt somit noch in der Gebärmutter. Wie sieht die "Alpha Vulkan API" aus, was kann die, ist sie schon gut entwickelt & brauchbar (ausser für ein paar 'closed API' Tech-Demos mit diversen Fehlern)

98% der bestehenden Game-Engines & Game Entwickler-Tool's haben keine Implementierung von Vulkan API. Also muss die Vulkan API zuvor erst einmal ihre "Leistungsfähigkeit" und somit ihre Daseinsberechtigung aufzeigen, gute und erhebliche Vorteile gegenüber bestehenden API's (Direct3D - DirectX 12 / OpenGL) bringen & auf allen Plattformen verfügbar sein. Wenn dies nicht der Fall ist - reicht's ja eventuell immer noch für die neue 'Linux API' (Steam OS) oder zur neuen Google Android API - mit abgespeckten Features.

=> Vulkan™ on Intel® Graphics at SIGGRAPH 2015 und wieder ist eine neue API in einer lächerlichen DEMO satte 50% schneller wie damals AMD's Mantle API 2014 - eine wahre Sensation ;o)
=> Introducing the 2015 Autodesk Stingray 3D Game Engine (Maya/LT / 3DsMax / Nvidia PhysX) - but no Vulkan!
=> Unreal Engine Sep 17, 2015 Livestream - GDC'13 "Infiltrator DEMO" Public Released - Live from Epic HQ / Unreal Engine 4 / 3DsMax & Nvidia APEX / PhysX) "Real-Time Interactiv UE4 - Infiltrator DEMO"

AMD Has A Vulkan Linux Driver, But Will Be Closed-Source At First - Phoronix Forums /// Vulkan API Analysis Part 1 | Overview, Purpose & Benefits Of Vulkan | Tech Tribunal RedGamingTech

Top 5 Game Engines For Developers - Framebench /// Desktop Operating System Market Share - Mac OS X - 4.76% / Linux - 1.63% / Windows - über 92% Marktanteil aller OS !
 

Anhänge

  • untitled2.png
    untitled2.png
    19 KB · Aufrufe: 40
Zuletzt bearbeitet:
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Late 2015 wäre zeitlich gesehen vermutlich der schnellste major API Release, den die KG zeitlich zur Konkurrenz je zum Markt gebracht hat.
Wenn sich mit Vulkan nichts bewegendes tut, dann vermutlich nie.

Mantle ist tot, interessiert folgerichtig niemanden mehr.
Vulkan sieht interessant aus, kann viel und ist schon gut entwickelt und brauchbar.

Wenn 98% der Game-Engines keine Implementierung von Vulkan haben, dann 96% keine mit DX12.
Beide brauchen noch einige Monate, wo Vulkan wohl gerne noch einige Monate draufschlägt.
Die Vorteile sind erheblich gegenüber OpenGL, gegenüber DX12 lautet sie hauptsächlich Multi-Platform.
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Was ist hier jetzt Marketing ? Das AMD eine Firma unterstützt tut doch Nvidia auch oder nicht ? Die hohen Latenzen sind bei einem Context Switch real anstatt sich wie eine kleines Kind zu verhalten um zu erzwingen dass AMD dieses Feature abschaltet sollte Nvidia lieber mit harten Fakten kommen anstatt irgendwas von Bugs zu reden die es es nie gegeben hat. Jetzt auf-einmal soll diese Feature per Software gelöst werden obwohl es vorher geheißen hat Maxwell ist voll DX12 fähig.
Einzelne Unternehmen zu unterstützen, die mediale Aufmerksamkeit bekommen ist natürlich Marketing.
Marketing ist ja nicht einfach nur Werbung im TV oder Magazinen, Marketing findet auf extrem vielen Ebenen statt.
Benchmarks manipulieren ist Marketing, Treiberfeatures gut verkaufen ist Marketing, OEMs Honig ums Maul schmieren.... Marketing.
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Was ist hier jetzt Marketing ? Das AMD eine Firma unterstützt tut doch Nvidia auch oder nicht ? Die hohen Latenzen sind bei einem Context Switch real anstatt sich wie eine kleines Kind zu verhalten um zu erzwingen dass AMD dieses Feature abschaltet sollte Nvidia lieber mit harten Fakten kommen anstatt irgendwas von Bugs zu reden die es es nie gegeben hat. Jetzt auf-einmal soll diese Feature per Software gelöst werden obwohl es vorher geheißen hat Maxwell ist voll DX12 fähig.
Herrje, weiß man gar nicht, wo man vor lauter falschen Behauptungen anfangen soll....

Also, zunächst mal ist ASync bei NVIDIA-Karten implementiert. Was NICHT implementiert ist (zumindest Stand heute) ist ein Wechsel Graphics/Compute ohne Context-Switch. Der ist aber mitnichten Teil von DX12, sagt sogar Oxide selbst:

I don’t believe there is any specific requirement that Async Compute be required for D3D12, but perhaps I misread the spec.

[/FONT][/COLOR]http://wccftech.com/...d-big-advantage-dx12-performance-oxide-games/

Also ist es erstmal für die DX12-Fähigkeit völlig irrelevant, ob Maxwell dieses Feature kann oder nicht.

Zweitens hat NVIDIA klar auch zu Oxide kommunziert, dass dieses Feature AKTUELL noch nicht implementiert ist:

"We actually just chatted with Nvidia about Async Compute, indeed the driver hasn’t fully implemented it yet, but it appeared like it was. We are working closely with them as they fully implement Async Compute.”
Asynchronous compute, AMD, Nvidia, and DX12: What we know so far | ExtremeTech

Dass man dann als Entwickler das Feature nicht nutzen sollte, solange es noch verbuggt ist, sollte klar sein. Das hat exakt null mit dem Verhalten eines kleinen Kindes zu tun.

Wenn du Verhalten wie ein kleines Kind sehen willst, kannst du es z.B. hier nachlesen.
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Herrje, weiß man gar nicht, wo man vor lauter falschen Behauptungen anfangen soll....

Also, zunächst mal ist ASync bei NVIDIA-Karten implementiert. Was NICHT implementiert ist (zumindest Stand heute) ist ein Wechsel Graphics/Compute ohne Context-Switch. Der ist aber mitnichten Teil von DX12, sagt sogar Oxide selbst:


[/FONT]http://wccftech.com/async-shaders-give-amd-big-advantage-dx12-performance-oxide-games/

Also ist es erstmal für die DX12-Fähigkeit völlig irrelevant, ob Maxwell dieses Feature kann oder nicht.

Zweitens hat NVIDIA klar auch zu Oxide kommunziert, dass dieses Feature AKTUELL noch nicht implementiert ist:


Asynchronous compute, AMD, Nvidia, and DX12: What we know so far | ExtremeTech

Dass man dann als Entwickler das Feature nicht nutzen sollte, solange es noch verbuggt ist, sollte klar sein. Das hat exakt null mit dem Verhalten eines kleinen Kindes zu tun.

Wenn du Verhalten wie ein kleines Kind sehen willst, kannst du es z.B. hier nachlesen.

den Context Switch muss die Hardware selbst machen nicht die Software, ist doch sinnlos so-etwas in Software zu machen das ist ja der eigentliche Witz dabei oder will man für jede Software die raus kommt wiederum Optimierungen machen und eine Datenflussanalyse/ Abhängigkeitsanalyse machen ohh wait das hat doch im Grunde schon Nvidia mit DX11 gemacht, ASync Compute beherrscht auch die CPU um diese besser auszunützen
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

den Context Switch muss die Hardware selbst machen nicht die Software, ist doch sinnlos so-etwas in Software zu machen das ist ja der eigentliche Witz dabei oder will man für jede Software die raus kommt wiederum Optimierungen machen und eine Datenflussanalyse/ Abhängigkeitsanalyse machen ohh wait das hat doch im Grunde schon Nvidia mit DX11 gemacht, ASync Compute beherrscht auch die CPU um diese besser auszunützen
Natürlich muss der ContextSwitch auch per Treiber gesteuert werden, es können auch einfach die zugrunde liegenden Treiber-Funktionen noch nicht vollständig implementiert sein.

Dass die aktuellen DX12-Implementierungen noch ziemlich unfertig und wackelig sind, sollte jedem Entwickler klar sein.

Lirum, Larum: Auch ohne jede Fähigkeit von ASync ist eine Karte völlig DX12-kompatibel.
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Natürlich muss der ContextSwitch auch per Treiber gesteuert werden, es können auch einfach die zugrunde liegenden Treiber-Funktionen noch nicht vollständig implementiert sein.

Dass die aktuellen DX12-Implementierungen noch ziemlich unfertig und wackelig sind, sollte jedem Entwickler klar sein.

Lirum, Larum: Auch ohne jede Fähigkeit von ASync ist eine Karte völlig DX12-kompatibel.

laut Aussagen von Oxide hatte Nvidia diese Code über ein Jahr, und all diese Statements seitens Nvidia hören sich nur nach Schadensbegrenzung an
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Link zu beiden Aussagen?


The Birth of a new API - Oxide Games


steht im ersten Absatz

"Unfortunately, we have to make some corrections because as always there is misinformation. There are incorrect statements regarding issues with MSAA. Specifically, that the application has a bug in it which precludes the validity of the test. We assure everyone that is absolutely not the case. Our code has been reviewed by Nvidia, Microsoft, AMD and Intel. It has passed the very thorough D3D12 validation system provided by Microsoft specifically designed to validate against incorrect usages. All IHVs have had access to our source code for over year, and we can confirm that both Nvidia and AMD compile our very latest changes on a daily basis and have been running our application in their labs for months. Fundamentally, the MSAA path is essentially unchanged in DX11 and DX12. Any statement which says there is a bug in the application should be disregarded as inaccurate information."




 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Lesen bildet.

Es geht explizit nicht um Async, sondern um MSAA.


ich hab ja gewusst das, das kommt, nur weil das jetzt im selben Absatz steht aber die Tatsache das Nvidia den Code solange hatte und selbst optimieren konnte lässt man außer acht. So kann man ja auch einen Post zerstückeln als nächstes kommt jedes Wort einzeln zu zerstückeln und dann zählen wie viele as und bs vorkommen in einem Absatz. Es geht nicht nur explizit darum über den den Bug was hat das mit der Tatsache zu tun dass alle Vendors den Code über ein Jahr hatten ? Sowohl AMD als auch Nvidia hatten die Möglichkeit den Code zu optimieren und das lange genug Bug hin oder her.

"All IHVs have had access to our source code for over year, and we can confirm that both Nvidia and AMD compile our very latest changes on a daily basis and have been running our application in their labs for months"
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

ich hab ja gewusst das, das kommt, nur weil das jetzt im selben Absatz steht aber die Tatsache das Nvidia den Code solange hatte und selbst optimieren konnte lässt man außer acht.
"den code" != ASync-Code

Seit wann hat Oxide denn Async implementiert?

Ich seh das Problem nicht. Ein Feature funktioniert nicht, das hat Oxide jetzt eben deaktiviert. Ganz einfach. Machen andere Developer doch auch, weil z.B. die Tessellation-Performance der Radeons nicht der Brüller ist. Das sind ganz normale Anpassungen an die normalen Gegebenheiten.

Wenn NVIDIA das Problem gefixt hat, kann Oxide Asnyc ja auch auf der NVIDIA-Karte nutzen.
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

"den code" != ASync-Code

Seit wann hat Oxide denn Async implementiert?

Ich seh das Problem nicht. Ein Feature funktioniert nicht, das hat Oxide jetzt eben deaktiviert. Ganz einfach. Machen andere Developer doch auch, weil z.B. die Tessellation-Performance der Radeons nicht der Brüller ist. Das sind ganz normale Anpassungen an die normalen Gegebenheiten.

Wenn NVIDIA das Problem gefixt hat, kann Oxide Asnyc ja auch auf der NVIDIA-Karte nutzen.

wo steht den in den Specs, dass man das explizit muss ?

Ja ok dann solll Nvidia mal machen aber auf Kosten von was ? der CPU Last ? hat AMD auch nicht.

Grundsätzlich geht es darum dass Nvidia lange genug den Code hatte und daher war die Möglichkeit ASync zu implementieren bereits gegeben, erwarte dir einfach nicht zuviel, dass Nvidia dann gleich noch mal 30% Prozent drauflegt wie es AMD gemacht hat. Selbst wenn das durch den Treiber gemacht werden soll, das Problem besteht grundsätzlich durch die Hardware weil bevor diese Switch gemacht werden kann müssen alle Buffer unter anderem auch die Caches geleert werden was anscheinend funktioniert das nicht so gut bei Nvidia Hardware. Es gibt auch eine Architektonischen Gesichtspunkt wenn man sich die Hardware etwas besser anschaut also das Blockschaltbild. Das Problem sind die Scheduler, bei Nvidia werden nur ganze Blöcke damit angesprochen, bei AMD können auch die einzelnen Einheiten als die des Blockes angesprochen werden . Sprich der Context Switcht funktioniert bei Nvidia nur global während dieser bei AMD auch lokal funktioniert. Die einzelnen Caches bzw. Buffer können schon während des Berechnens geleert werden während man bei Nvidia warten muss bis alle Berechnungen fertig sind, für jeden Block natürlich und dann können erst die Caches geleert und neu aufgefüllt werden (soviel ich verstanden hab).
 
Zuletzt bearbeitet:
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

Wenn NVIDIA das Problem gefixt hat, kann Oxide Asnyc ja auch auf der NVIDIA-Karte nutzen.

Jaein, wenn der Treiber weiterhin die Task an die CPU schickt kann man das Feature zwar nutzen, es bleibt aber ein Workaround. Wenn sie die Task dann über die GPU abwickeln, müssen sie einen Context-Switch durchführen was auch nicht so clever ist.

Lirum,Larum: ;) Es bleibt nicht performant nutzbar.
 
AW: Nvidia Pascal: GP100-GPU womöglich in der Testphase, als Geforce mit max. 16 GiByte HBM

In der DX12 Spec ist ASync nicht spezifiziert. Du darfst gern das Gegenteil nachweisen.

Solange die Performance hinterher in Ordnung ist, ist es doch völlig egal, WIE NVIDIA es nun konkret löst.

Grundsätzlich geht es darum dass Nvidia lange genug den Code hatte
Unbewiesene Behauptung.

und daher war die Möglichkeit ASync zu implementieren bereits gegeben
Ja, nur ist es eben nicht vollständig. So wie z.B. bei AMD DX11 oder Tessellation. Nur wird da kein Fass aufgemacht sondern im Gegenteil ein Entwickler, der z.B. viel Tessellation nutzt automatisch als bezahlt von NVIDIA diffamiert wird.

erwarte dir einfach nicht zuviel, dass Nvidia dann gleich noch mal 30% Prozent drauflegt wie es AMD gemacht hat.
Wie auch? NVIDIA hat die Performance auch unter DX11 im Griff und vernichtet AMD dort gnadenlos. Logisch, dass man da beim Wechsel auf DX12 keine Wunder erwarten kann. AMDs "Vorteil" ist doch nur, dass sie unter DX11 Schnarchlangsam sind.

Siehe:
http://www.extremetech.com/wp-content/uploads/2015/08/DX11-High.png
http://www.extremetech.com/wp-content/uploads/2015/08/DX12-High.png

Wenn NVIDIA das Problem löst und die Performance unter DX11 und DX12 identisch ist, sind sie immer noch schneller als AMD.

Was willst du mehr erwarten?
 
Zurück