FEMFX: AMDs neue Programmbibliothek für Physik per CPU-Multithreading
AMDs FEMFX soll Spieleentwicklern auf Basis der numerischen Finiten-Elemente-Methode (FEM) eine einfache sowie umfangreiche Implementierung verformbarer Materialphysik ermöglichen und dem Trend zum CPU-Multithreading Rechnung tragen.
AMD hat mit FEMFX eine neue Physik-Bibliothek zur Berechnung von Effekten per CPU als Bestandteil seiner Middleware GPUOpen vorgestellt, die eine Vielzahl von verschiedenen Materialien und Wechselwirkungen zwischen selbigen simuliert. Dazu zählt laut Beschreibung unter anderem realistisch aussehendes Holz, Metall, Kunststoff oder Glas, die sich unter Belastung biegen und brechen sollen wie echte Materialien. Interessant: Fast zeitgleich stellte Nvidia in Aussicht, PhysX 5 im kommenden Jahr zu veröffentlichen.
Die wichtigsten Funktionen von FEMFX:
- Elastische und plastische Verformung
- Implizite Integration für Stabilität bei steifen Materialien
- Kinematische Steuerung von Mesh-Eckpunkten
- Bruch zwischen tetraedrischen Flächen
- Nicht brechende Flächen zur Kontrolle der Form von Rissen und Stücken
- Kontinuierliche Kollisionserkennung (CCD) für schnell bewegte Objekte
- Einschränkungen bei der Kontaktauflösung und der Verknüpfung von Objekten untereinander
- Einschränkungen zur Begrenzung der Verformung
- Dynamische Steuerung der Tetraeder-Materialparameter
- Unterstützung für das Verformen eines Render-Mesh unter Verwendung des Tetraeder-Mesh
Die Darstellung der Materialphysik auf Basis der numerischen Finiten-Elemente-Methode (FEM) ist dabei nicht nur visueller Natur, sondern die simulierten Materialien widerstehen oder schieben sich auch gegen andere Objekte zurück. Entwickler sollen dabei die Einstellungen ganz leicht ändern können, damit sich das gleiche Objekt sehr unterschiedlich verhält, zum Beispiel gelatineartig oder schmelzend. Neben dem optischen Aspekt sollen sich dadurch auch interessante physikalische Interaktionen für Gameplay oder Rätsel in Spielen ergeben.
Laut AMDs setzt FEMFX umfangreich auf Multithreading, um Multicore-CPUs zu nutzen und vom Trend der steigenden Prozessorkernzahlen zu profitieren. Entwickler können die FEMFX-Bibliothek und Beispielcode über Github herunterladen, ebenso wie ein Plug-in für die Unreal Engine. Einen Eindruck von FEMFX liefern die GIF-Animationen in der untenstehenden Bildergalerie. Erstmals gezeigt wurde die Technik bereits Mitte des Jahres beim Unreal Fest.
Bildergalerie
Quelle: via dsogaming.com
Exakt das! Einfach nichts besonderes erwarten und fertig.
Mal ganz banal:
AMD muss doppelt so viele Baustellen abdecken wie Nvidia, also erwarte ich nur 50 Prozent und alles was mehr als halb so gut ist wie das von Nvidia ist schon gut und nicht schlecht.
Dann ist AMD aber weniger als halb so groß, Also werden aus 50 mal eben nur noch 25 Prozent die ich erwarte.
Ich denke wir sind uns einig dass AMD nicht 75 Prozent weniger liefert als Nvidia, oder?
Genau so SEHE ICH DAS und genau deshalb hat mich diese Aussage gestört.
Anders:
Stellt euch eine Firma vor in der seit 30 Jahren Menge X produziert wird. Jetzt wird aber 15 Prozent mehr Personal eingestellt und innerhalb von drei Jahren produziert man 80 Prozent mehr. Dann sind die paar People nicht einfach etwas besser als die anderen, die sind der burner.
Hier haben wir eine kleine Firma die jahrelang am Boden war, offiziell die Radeon Group auf Sparflamme gekocht hat (2 Jahre) und jetzt erst wieder anfängt zu arbeiten. Dann kommst du und wunderst dich dass sich zwei Jahre + nichts getan hat. Das wirkt auf mich eher logisch und nicht schwach.
Ich denke wir sehen die gleichen Dinge, nur werte ich sie anders.
Gesendet von meinem HTC U12+ mit Tapatalk
Da erwarte ich auch keine große Verbreitung oder überhaupt.
Sony und Microsoft arbeiten auch nur mit einer einzigen Hardwarekonfiguration und nicht mit tausenden. Das ist der schlimmste Vergleich der nur geht.
Aber die Compiler-Arbeit, dass übersetzen von einem Shader zur GCN-Maschinensprache, ist effektiv beständig und zu großen Teilen unabhängig von restlichen Faktoren.
Die Compute Units sind von GCN1 bis GCN5 zu über 95% gleich geblieben, was das Ausführungsmodell und die Features angeht.
Es war 2013/14 vermutlich nicht für jeden überraschend, dass Sony und MS, die um ein Mrd. schweres Konsolengeschäft bullen und tausende SW-Leute beschäftigen, da Teams aufstellen können, welche bessere Compiler schreiben, aber 2016 war AMDs Compiler nach wie vor schlechter und laut einem id Software Entwickler (Aussage von 2018 oder 2019) ist der Compiler nach wie vor nur mittelmäßig.
Vor ein paar Jahren hatte mal einer der von AMD zu Intel gewechselt ist im Interview gemeint dass zu dieser Zeit gerade mal 25! Mitarbeiter im AMD Treiber Team waren.
Nvidia hatte da ein Beispiel gebracht wo sie schon 50 Mitarbeiter zu einem einzigen Entwickler geschickt hatten um diesen bei der Einführung von gameworks zu unterstützen.
AMD bietet standardmäßig kein Vulkan-Support für GCN1 und GCN2 an, weil für die GPUs stehen zwei Kernel-Treiber zur Auswahl, der alte Radeon-Kernel und der relativ neue AMDGPU-Kernel.
AMDGPU wurde dabei auf Hawaii(GCN2) zuerst entwickelt.
Jetzt sind 3+ Jahre her und GCN2 verwendet nach wie vor nicht AMDGPU als Kerneltreiber, dass hätte man schon deutlich früher lösen können oder als Standard setzen und sich den Regressionen stellen, stattdessen wird das so dahergeschleppt.
Ähnlich sieht es beim User-Mode-Treiber aus.
AMD bietet zwei Versionen davon.
Den eigenen offenen AMDVLK-Treiber, welcher auch einen Open-Source-Compiler (LLPC) auf Basis von LLVM verwendet und AMDVLK Pro, welcher im Prinzip der gleiche Treiber ist, nur mit einem geschlossenen Compiler, welcher bessere Ergebnisse liefert.
Laut AMD ist der Plan den geschlossenen Compiler völlig durch LLPC (offener Compiler) zu ersetzen, wenn die Performance auf einem Niveau liegt.
Der offene AMDVLK-Treiber ist seit Dezember 2017 verfügbar, es sind 2 Jahre vergangen und es sieht nicht so aus, als ob AMD in naher Zukunft AMDVLK Pro fallen lassen würde.
Daneben gibt es Valve, welche einige Leute für einen neuen Compiler angeheuert haben und voila, in unter zwei Jahren gibt es einen neuen Compiler, der die anderen Nass macht.
Man könnte ja noch andere Dinge debattieren, wie den OpenCL-Support unter Navi, welcher nur eine jämmerliche Performance zu Stande bekommt.
ROCm gibt es noch nicht für Windows und der unterstützt auch Navi unter Linux nicht.
Also wenn AMD es schon nicht schafft Treiber und Compiler zeitlich zu entwickeln und stellenweise nicht einmal für die eigene HW die Besten entwickelt, selbst nach etlichen Jahren "Schonzeit", was soll man dann von AMDs restlichen Bemühungen erwarten?
Ich weiß nicht wieso AMD Leute beschäftigt, um eine kleine CPU-Physik-Bibliothek zu schreiben, als ob man sonst nichts zu tun hat.
Da erwarte ich auch keine große Verbreitung oder überhaupt.
Das Ergebnis ist RADV, welcher zusammen mit einem neuen und nicht von AMD geschrieben Compiler auch konsistent den offenen Vulkan-Treiber von AMD schlägt
Das LLVM-Compiler-Backend klang anfangs auch noch nach einer guten Idee, da NIR in Mesa noch nicht existierte und man so bereits existierende Optimierungen von LLVM nutzen konnte. Inzwischen ist das eher ein Irrweg mit schlechter Performance, extrem langen Compile-Times, haufenweise Fehlern (und die werden nicht weniger), und einem halbjährlichen Release-Zyklus, der effektiv verhindert, dass Probleme zeitnah gelöst werden können. Ich habe auch nicht den Eindruck, dass AMD einen klaren Plan hat, wie es damit weitergehen soll.
Ursprünglich sollte LLVM ja wohl mal das proprietäre Backend (das anscheinend ursprünglich gar nicht von AMD, sondern einer externen Firma entwickelt wurde, aber eine wirklich handfeste Quelle dafür habe ich nicht) ablösen, aber dazu dürfte es in absehbarer Zeit nicht kommen.
Da hätte ich bei Nvidia und Intel noch mehr Gründe um diese trockenzulegen.