Alles rund um Compiler und Softwareentwicklung

Nvidia hat das geschafft. Gut, die haben deutlich mehr Ressourcen. Aber über die Jahre hätte man wirklich etwas an der Treiber Leistung nachbessern können/müssen.
AMD zumeist höhere Rohleistung kam nie richtig an.
 
Ich habe mir den Artikel von Herrn Stiller in der c't zum Thema C++-Compiler durchgelesen. Getestet wurden unter Windows Microsofts Visual Studio 2015, unter Windows und Red-Hat-Linux Intels Parallel Studio X2016 sowie nur unter Linux die GNU Compiler Collection GCC 5.3.0. Bei "normalem" Code ist der Unterschied wirklich nicht überwältigend (ca. +15 % Vorsprung für Intel vor Microsoft und GCC).
Richtig krass wird es jedoch, sofern man sehr Fließkomma-intensive Berechnungen mit Autovektorisierungspotential (SSE, AVX) kompiliert. Dort kann dann die Intelsche Compiler-Magie schon mal eine Beschleunigung um den Faktor 70 (auf einem Intel-System) herausschlagen. Es wird auch deutlich, dass Compiler sehr launische Magier sind. Hier und da verpufft die Magie schon durch eher kleine Änderungen am Quellcode.
 
http://www.planet3dnow.de/cms/22761-amd-stattet-cgg-mit-firepro-gpus-aus/
Dass AMDs Initiative GPUOpen so schnell auch in der Praxis Anwendung findet hat mich jetzt überrascht. Hier scheinen wirklich ganz andere Seiten in Bezug auf Software aufgezogen worden zu sein.
Employing AMD’s HPC GPU Computing software tools available on GPUOpen.com, CGG rapidly converted its in-house Nvidia CUDA code to OpenCL™ for seismic data processing running on an AMD FirePro™ S9150 GPU production cluster, enabling fast, cost-effective GPU-powered research.
Zum Vergrößern anklicken....
Da scheint der CUDA Converter in vollem Einsatz zu sein und tatsächlich praktisch Nutzen zu entwickeln für AMDs Kampf um Marktanteile

Beim stöbern auf der GPUOpen Seite entdeckte ich diese Sammlung an DX11 Tools:
http://gpuopen.com/games-cgi/
TresFX war mir ja bekannt, doch ShadowFX, GeometryFX und AOFX nicht.
Das liest sich wie eine Liste von Libraries, die genau die größten Problemzonen durch Nvidias Gameworks adressieren. Zuletzt gab es ja da mit Schatten und HBAO+ Schwierigkeiten. Und GeometryFX wirkt wie etwas, dass dem Tesselation Overkill der Nvidia-gesponsorten Titel entgegenwirken soll.

Kann das jemand bestätigen, der detailliertere Kenntnisse um die Gameworks-Situation hat?

Edit:
Also wenn ich das richtig verstehe: http://gpuopen.com/gaming-product/geometryfx/
Dann ist er Ansatz den AMD geht mit GPUOpen ja einfach genial!
Wenn Nvidias Vorgaben für Sponsoring einen Tesselationlevel von 64x vorschreiben, dann bietet GPUOpen die Möglichkeit einfach zusätzlich GeometryFX einzusetzen, welche in einem "pre-pass" alles wieder raus filtert was nicht sichtbar ist um die GPU nicht unnötig zu belasten. Sozusagen ein "Heilmittel" gegen Gameworks-AMD-Bremsen.

Was hier so genial finde, ist dem ausweichen der Notwendigkeit einer eigenen Gameworksartigen API, sondern einfach eine Toolsammlung die frei verfügbar ist um Drawbacks für AMDs Produkte wieder auszugleichen. Die Entwickler müssen sich nicht mit Nvidia rum streiten, da die AMD Optimierungen in Form einer Library kommen und einfach negative Effekte wieder ausgleichen - das offensichtlich mit Hilfe der besseren Compute-Fähigkeiten ohne große Leistungsverluste.
 
Zuletzt bearbeitet:
Aber die Spielentwickler müssten das integrieren? Aber warum sollten sie das, wenn sie an Gameworks teilnehmen?
 
Daher eine Library. AMD Fallback Code müssen sie ja sowieso einbauen. Ich denke der Aufwand wird geringer sein, als selber daran rum zu basteln. Und Nvidia kann ja nicht verbieten für AMD zu optimieren, sondern lediglich vorschreiben mit welchen Settings Gameworks zu implementieren ist.

Zuletzt haben die Verkäufe gelitten bei Titeln die so eindeutig schlechte Performance hatten.
 
@ cyrusNGC_224
Weil sie so am Gameworks Programm teilnehmen und gleichzeitig schädliche Effekte wie eine überzogene Tesselation herausfiltern könnten.
Der Witz an der Sache ist ja das gerade beim Punkt Tesselation auch die Geforce Fraktion davon profitieren könnte denn bei AMD kann man den Tesselationsfaktor im Treiber begrenzen aber bei den Geforce Treibern? Sie profitieren dabei ebenso von einer höheren Framerate.
 
Bestrebungen, CUDA Code in OpenCL Code zu übersetzen, gibt es ja schon länger. Mal schauen, ob AMDs Lösung das letzte Puzzleteilchen ist, damit dies auch Unternehmen schnell und effizient bewerkstelligen können. Der erste Schritt scheint gemacht. Kann man nur hoffen, dass andere zügig nachziehen.
 
GeometryFX klingt irgendwie nicht nach tesselation, sondern nach einer fix und fertigen Lösung für Occlusion Culling, die aber auch einen anderes nettes Feature besitzt, denn Drawcalls können zusammengefasst werden.
 
solche Sichtbarkeitsprüfungen sind doch ein alter Hut. Wenn ich mich recht erinnere wird dafür der Z-Buffer genutzt.
 
Nur eben nicht ohne Leistungsverlust in Quasi-Echtzeit dank verbesserter Computing Fähigkeiten.
 
Complicated schrieb:
Wenn Nvidias Vorgaben für Sponsoring einen Tesselationlevel von 64x vorschreiben...
Zum Vergrößern anklicken....
Die Voreinstellung im CNext für Tesselation ist "AMD Optimized", womit der Override für das Tesselationlevel aktiviert wird.

Diese Option besteht seit 2011 und seitdem kann sich der Display Driver über die Vorgaben der Spieleengine hinwegsetzen.
 
Na das ist ja ein Hammer:
http://www.planet3dnow.de/vbulletin/showthread.php?t=425071
Originalquelle:
http://venturebeat.com/2016/03/09/o...-the-best-graphics-software-across-platforms/
Otoy has ported the CUDA language to run on AMD, Intel, and ARM GPUs for the first time ever. That means any application written in CUDA can run, without modification, on all major chipsets and platforms. While there is an independent GPGPU standard dubbed OpenCL, it isn’t necessarily as good as CUDA, Otoy believes.
[...]
“It’s pretty ready, and it answers questions about whether this could be done,” Urbach said. “It runs on the other cards at the same speed as it runs on Nvidia cards.”
Otoy will be building new backends to this framework to allow CUDA to target alternative applications programming interfaces (APIs) such as Vulkan, DirectX, and OpenGL – across Android, Playstation 4 and WebGL 3 (the latter with the help of JavaScript creator Brendan Eich).
Zum Vergrößern anklicken....
Und bei solchen Sätzen muss ich immer lachen und frage mich warum sie keinen Technikguy nochmal drüber lesen lassen:
As an example, CUDA has something called “compute shaders” that allow for much more advanced graphics effects, Urbach said.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Wenn es so schnell wie auf nVidia Karten läuft, die AMD Pendants aber idR. deutlich mehr Rohleistung haben, dürfte da dennoch Potenzial für Optimierung sein.

Warum sollte nVidia keine Compute Shader haben? Deren Problem sind nur die Context Switches, d.h. entweder Grafik oder Compute.
 
Bei Anandtech ist ein Artikel zu einem Vergleich zwischen Intels Xeon-Dickschiffen und IBMs Power8-Chips erschienen. Die letzten werden hier mangels Softwarebasis kaum jemanden interessieren, aber beim Vergleich der Speicherbandbreite ist ein interessantes Detail enthalten: Intels aktuellen Xeons kann man die volle Bandbreite nur mit vektorisierten Maschinenbefehlen abtrotzen, sonst bleibt doch einiges davon liegen.
http://www.anandtech.com/show/10435/assessing-ibms-power8-part-1/7
Wenn man demnächst einen AMD Zen mit einem Intel Xeon vergleicht, sollte man das im Hinterkopf behalten. Nicht das man nicht-vektorisierten Maschinencode auf dem Zen gegen vektorisierten auf dem Xeon vergleicht.
 
Nach AMD rüsten jetzt auch Intel und nVidia Ihren OpenCL-Support auf Version 2.0 auf

nVidia hing bisher noch bei OpenCL 1.2 fest, hat sich auch eher auf CUDA fokussiert. Jetzt reichen sie OpenCL 2.0-Support nach. Das könnte man als Zeichen verstehen, dass OpenCL gegenüber CUDA weiter an Bedeutung gewinnt, denn vermutlich würden sie am liebsten weiter ihre eigene Suppe kochen, wenn der Markt das akzeptieren würde.
https://www.phoronix.com/scan.php?page=news_item&px=OpenCL-2.0-NVIDIA-Preps

Intel rüstet auch unter Linux auf OpenCL 2.0 auf: http://www.phoronix.com/scan.php?page=news_item&px=Intel-Beignet-1.3-Released

Die Software Darktable zur Entwicklung von Bildern im RAW-Format kommt in Version 2.2 mit einem verbesserten OpenCL-Support. Bei Benchmarks des Portals Phoronix war Darktable mit AMD- und nVidia-Grafikkarten gleich schnell:
Similar to our other OpenCL benchmarks we have carried out in the past with Radeon GPUs using the AMDGPU-PRO driver, this proprietary OpenCL stack overall performs competitively with GeForce GPUs on the latest NVIDIA Linux drivers. It will be great once that AMD OpenCL stack is fully open and widely usable, hopefully we'll see that milestone achieved in 2017.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
In der Vergangenheit hieß OpenCL-Support bei Intel immer Support für die CPU-Kerne.
Ich habe den Eindruck, dass Phoronix über Intel GPU Support redet, Intel jedoch nicht.
MfG
 
Auf der SIGGRAPH 2018 wurden die Pläne für OpenCL-Next vorgestellt. Die neue Version der Spezifikation erscheint 2019 und soll für Graka-Hersteller einfacher zu implementieren sein. Auch nVidia soll die nächste Version von OpenCL weiterhin unterstützen.

Bei den Features stecke ich nicht so tief in den Details, aber wie es aussieht, wird unter anderem die Portabilität bzw. das Zusammenwirken von OpenCL mit Vulkan verbessert.
https://www.phoronix.com/scan.php?page=article&item=siggraph-2018-khr&num=2
 


Schreibe deine Antwort....

Ähnliche Themen

H
Ur-alter Benchmark Dhrystone2
Antworten
1
Aufrufe
1K
HITCHER
H
eratte
Download HandBrake 1.3.0 für Windows, Mac und Linux vefügbar.
Antworten
3
Aufrufe
2K
Hotstepper
Hotstepper
E555user
News OCAT exe in v1.2 von Rys Sommefeldt auf GitHub
Antworten
1
Aufrufe
957
derDruide
derDruide
eratte
MSI A88XM Gaming & A10 7860k und DDR3 2100 vs Gigabyte GA-B85M-D2V (rev. 3.0) & Intel i3 4130 und DDR3 1600
2
Antworten
37
Aufrufe
14K
eratte
eratte
eratte
News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)
31 32 33
Antworten
802
Aufrufe
112K
E555user
E555user
Zurück
Oben Unten