Alles rund um Compiler und Softwareentwicklung

@derDruide
OpenCL-Next?
Vulkan = Low-Level?

Die Features müsste ich auch zuerst Nachlesen.

the 2990WX takes that ball and runs with it, making it a niche of a niche. To be honest, it doesn’t offer enough cases where performance excels as one would expect – it makes perfect sense for a narrow set of workloads where it toasts the competition. It even outperforms almost all the other processors in our compile test. However there is one processor that did beat it: the 2950X.
Source-Code: https://www.anandtech.com/show/13124/the-amd-threadripper-2990wx-and-2950x-review/15
thx @ fortunes @ hwluxx

Es wird wohl eine Flut an Anwendungen (bzw. x64 Programme) kommen. :)
 
OpenCL-Next ist die nächste Hauptversion von OpenCL, vermutlich wird das OpenCL 3.0 (die aktuelle Version ist 2.2)
Vulkan ist der weit effizientere Nachfolger von OpenGL und als low level API im Gegensatz zum lahmen DirectX 12 auf allen Plattformen vertreten: Linux, Windows, Android, macOS und iOS (beide Apple über die Zwischenschicht MoltenVK, weil Apple es mal wieder elitär möchte)
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Nehme an, weil NV das so will. Sie wollen nicht Vulcan pushen, weil sie in OpenGL größeren Vorteil gegenüber AMD haben. Das ist wie mit DX11 und DX12. Jetzt mit DXXR haben sie keine Wahl mehr ;)

Hier wohl eher OT, aber ich trau denen einfach nicht. Man kann denen zwar kaum ankreiden, da es halt sauber läuft, daß sie DX11 gehackt haben und dem da teils eine Art Parallelität verleihen, wo es das eigentlich nicht kann. Bei Vulcan aber ist die Sache eher klar. Das hat für mich nichts mit Architekturen von Hardware wie Treiber zu tun. Das möchten die einfach nicht, weil sie da keinen Treibervorteil mehr haben können.
Damit bringt AMD gegenüber NV plötzlich ;) die theoretische Leistung auch real auf den Schirm.

Und deswegen ist DirectXR eben super. Weil es an sich DX12.2 ist. Damit entfällt bald jegliches Treibergehacke komplett. Weniger super ist halt, daß man dafür das s.g. Kack-Win10 braucht ;)
 
Zuletzt bearbeitet:
Feel free to share:

 
Das mag ich so an Linux: Ein Entwickler von Darktable* hat das Scheduling für die ältere Piledriver-Architektur nochmal optimiert und zwischen 1 % und 7 % Verbesserung erzielt. Für die Analyse hat er neuere Tools des LLVM-Compilers benutzt.
https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Clang-2018-Bdver2-Tuning

Auch wenn der Artikel für mich so klang, als seien die 7 % eher die Ausnahme, ist jede Verbesserung für ältere Architekturen cool.

*für alle, die es nicht kennen: Mit Darktable entwickelt man RAW-Aufnahmen unter Linux
 
Zuletzt bearbeitet:
*für alle, die es nicht kennen: Mit Darktable entwickelt man RAW-Aufnahmen unter Linux

Nicht nur Raw, da ist Rawtherapee eigentlich besser, vielmehr ist Darktable eine Alternative für Adobes Lightroom ;)
 
Handbrake 1.2 ist erschienen und unterstützt jetzt endlich AMDs Video Encoding Engine (VCE). Kurioserweise geben die Entwickler an, dass das Feature offiziell nur ab Radeon RX 400 und mit Windows unterstützt wird. Andere Systeme und GPUs "können auch funktionieren", sind aber halt offziell nicht unterstützt / getestet. Ich sehe dank der technischen Basis aber keinen Grund, warum es nicht auch unter Linux funktionieren sollte.

Bei den Libraries sind die Entwickler für die Schritte Decoding und Filter von LibAV auf FFmpeg 4.1 umgestiegen (betrifft eventuell nur Linux?). Ferner werden jetzt x264 Version 157 und x265 V2.9 unterstützt.
 
Zuletzt bearbeitet:
Der Präsident von Khronos hat sich zur Entwicklung von OpenCL geäußert. Auch wenn Vulkan und OpenCL etwas überlappen, haben beide ihre Berechtigung und werden aktiv weiterentwickelt.
https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-OpenCL-Interop-2019

Desweiteren stellt Mozilla sechs weitere Programmierer für Thunderbird ein und will auch hier besser für multi-core optimieren. Das Team war 2018 schon gewachsen und man kann sagen, dass die Entwicklung wieder richtig Fahrt aufnimmt.

Unter Linux beklagen die Chrome-Entwickler die vielen Fehlermeldungen von nVidia-Nutzern mit nouveau-Treiber und gehen sogar so weit, die Hardware-Beschleunigung (WebGL) für diese User abzuschalten. Wer Linux nutzt oder dies plant, weil sonst Windows 10 droht, sollte weiterhin zu AMD greifen.
 
Zuletzt bearbeitet:
Das neue Handbrake 1.3 unterstützt AMDs VCE jetzt auch unter Linux. Technisch wird die Funktionalität über AMDs Media Framework (AMF) in der Version 1.4.9 realisiert.
 
Zuletzt bearbeitet:
Handbrake 1.4 wurde veröffentlicht: https://handbrake.fr/

Die Entwickler heben in der kurzen Liste der wichtigen neuen Features sechs Punkte hervor, zu denen auch verbessertes Hardware Encoding via AMDs VCN zählt. Dabei fällt auf, dass sie sich explizit bei den Herstellern AMD, ARM und Intel für die Verbesserungen an Handbrake bedanken ("Thanks to these companies all for supporting the development in HandBrake!").

Updates to the AMD VCN encoder:
  • Quality tuning for VCN's constrained vbr rate control mode. Results are the same or better than cqp mode, and bit rate is much more predictable.
  • Included optimised H265 presets for 1080p and 4K content.

Handbrake 1.4 inkludiert das AMD Advanced Media Framework (AMF) 1.4.18, FFmpeg 4.4, x265 3.5 und dav1d 0.9
 
Zuletzt bearbeitet:
Bei der Videobeschleunigung über den Vulkan-Standard ("Vulkan Video Extensions") geht's weiter voran. Der Support für das Decoding von H.264 über Vulkan wurde für alle AMD-Grafikkarten unter Linux veröffentlicht, bis runter zu den alten GCN 1-Modellen. Später folgen weitere Codecs (AV1, VP9, H.265) sowie das Encoding über Vulkan. Danach können die Multimedia-Frameworks wie FFmpeg die Technik einbauen, sodass Software wie Handbrake automatisch davon profitiert.

Die neue Blender-Version 3.0 wird AMDs HIP unterstützen, als besseren Ersatz für den gestrichenen OpenCL-Support. Diese Version soll zum Jahresende erscheinen, für Linux wird der Support in Version 3.1 nachgerüstet. Weitere Umbauten zur Nutzung von Vulkan Compute sollen zum Jahresende 2022 fertig sein.

 
Zuletzt bearbeitet:
Golem hat auch einen Artikel zu Blender 3.0, wo HIP beschrieben wird als ...
eine C++-Laufzeit-API sowie Kernel-Sprache, die das Erstellen von Programmen auf AMD- und Nvidia-Grafikkarten aus einem einheitlichen Quellcode ermöglichen soll. HIP soll auch eine einfache Migration von Cuda-Code ermöglichen.


Die Konvertierung von CUDA zu HIP soll weitgehend automatisch erfolgen, nur minimale Korrekturen sind wohl nötig. Das mit dem "dauerhaften Alleinstellungsmerkmal durch proprietären Krempel" ist dann wohl vorbei.

Scheinbar dient HIP auch in vielen Fällen als Nachfolger von OpenCL, sonst hätte AMD ja einfacher OpenCL in die neue Blender-Engine einbauen können. Weiß jemand, worin sich die Ansätze unterscheiden?

PS: Warum sieht der Golem-Link eigentlich anders aus als die zwei Links darüber? Der Code scheint gleich zu sein.
 
Zuletzt bearbeitet:
PS: Warum sieht der Golem-Link eigentlich anders aus als die zwei Links darüber? Der Code scheint gleich zu sein.
Je nach dem, wer es Hostet ?

Programmieren besteht aus 99,99% aus Mathematik.
Das ist vielen einfach zu viel.

Allerdings, wer genug Leidenschaft hat und sich reinhängt, wird am Ende entlohnt.
Leidenschaft, lässt sich nicht so einfach definieren, denn sie wird jeden Tag neu definiert. ;)
 
Je nach dem, wer es Hostet ?
Ich wollte es erst nicht glauben, aber jetzt fällt der Groschen. Beim Einfügen des Links wird das CMS von P3D sich die Überschrift von der Ziel-Seite holen, was bei Phoronix klappt und bei Golem nicht.
 
Zurück
Oben Unten