Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Hardware>ARM Mac: Raytracing und USB 4

ARM Mac: Raytracing und USB 4

subjore01.07.2010:34
Apple hat bei der WWDC ausgiebig betont wie toll ihre neue Grafikeinheit so wird. Meint ihr das bedeutet, dass sie dann auch Raytracing unterstützen werden? Und kommt Raytracing dann auch zum A14 Prozessor?
So wie Nvidia Raytracing implementiert hat benötigt es Neuronale Netze um effektiv zu funktionieren. Das dürfte bei Apples Chips kein Problem sein, da sie ja immer betonen wie groß ihre "neural engine" ist. Dieses Jahr kommt Raytracing auch in die neuen Konsolen, weshalb es vermutlich ein guter Zeitpunkt ist das jetzt auch zu unterstützen.

Der zweite Punkt den ich mich frage ist, ob Apple USB 4 in ihre neuen Computer verbaut.
Apple will beim Umstieg auf eigene Prozessoren gewiss nicht auf Thunderbolt verzichten. USB 4 wäre Rückwärtskompatibel zu Thunderbolt 3. Alternativ müssten sie nur für diese Computergeneration einen eigenen Controller entwickeln und vermutlich auch an Intel Lizenzkosten zahlen.
Laut Berichten sollen die ersten USB 4 Geräte Ende des Jahres erscheinen. Laut einem Ming-Chi Kuo kommen die USB 4 Macs aber erst 2022.
0

Kommentare

Crypsis8601.07.2011:11
tja, da sind noch sehr viele Fragen offen.

Die Analysten liegen ja auch durchaus mal falsch, aber nachdem Apple Thunderbolt3 so gepusht hat die letzten Jahre, wäre es schon extrem assozial, dass jetzt wieder fallen zu lassen. Wenn ich jedoch einem zutraue, USB4 "aus dem Hut zu zaubern" dann Apple. Ich persönlich habe aber meine eGPU schon verkauft, nachdem das mit FCPX ja schon seit längerem nicht mehr problemlos (bei mir) funktioniert. Da ist dann aber die Frage, wie geht es mit den eGPUs weiter? Apple weiß ja seit 4 Jahren, dass sie auf ARM wechseln, erst danach haben sie die eGPU eingeführt. Es besteht also leise Hoffnung.. Ebenso bei TB3/USB4..

An Raytracing glaube ich persönlich nicht. Apple hat im gaming Bereich noch genügend andere Baustellen (siehe Artikel von vorhin), da müssen sie jetzt nicht mit Raytracing ankommen.
+2
pünktchen
pünktchen01.07.2011:27
Metal unterstützt Raytracing.
+5
Zeichner
Zeichner01.07.2011:40
Ich hoffe sehr, dass Apple mit Ihren ARM-GPUs richtig Gas gibt. Ray Tracing muss kommen. Es geht nicht nur um Gaming, sondern um Anwendungen im 3d-Bereich. Sprich 3d-Renderings z.B. mit Cinema4d. Die meisten Programme dieser Art bieten neben dem üblichen CPU-Rendering, mittlerweile Echtzeit-Rendering mittels GPU an. Da wird sich im Bereich Ray Tracing in Zukunft noch viel tun.
Zudem hoffe ich, dass es auch Macbooks geben wird mit richtig starker GPU. In der Windows-Welt hat man von eGPUs nicht viel gehört, da z.B. Laptops von Razer, Alienware, etc. gleich mit entsprechend starken GPUs verfügbar waren.
Wobei man ja mit der 5600m sieht, dass Apple schon mal in die richtige Richtung geht.
0
vasquesbc
vasquesbc01.07.2011:44
Crypsis86
aber nachdem Apple Thunderbolt3 so gepusht hat die letzten Jahre, wäre es schon extrem assozial, dass jetzt wieder fallen zu lassen.

Nicht ganz ernst gemeinte Spekulation:
Wer weis, wie konsequent sie die Trennung von Intel verfolgen - vielleicht kommt als nächstes „Lightning Extreme“
„Allwissend bin ich nicht; doch viel ist mir bewußt.“
+1
athlonet01.07.2011:47
vasquesbc
Nicht ganz ernst gemeinte Spekulation:
Wer weis, wie konsequent sie die Trennung von Intel verfolgen - vielleicht kommt als nächstes „Lightning Extreme“

Oder ein neues Firewire
+1
Thyl01.07.2013:03
Wenn ich es richtig verstanden habe, hat ja intel für USB4 Thunderbolt freigegeben. Damit sinken möglicherweise die Kosten. Spannend finde ich auch die Idee, dass aufgrund der völligen Entwurfsfreiheit bei den eigenen Chips Apple die USB4/Thunderbolt-Controller direkt in das SoC integrieren könnte, womöglich sogar quasi ohne vorgeschaltetes PCIe. Signale sind zwar PCIe-Signale, aber vielleicht ist eine direktere Anbindung an den Prozessor auch möglich.

Übrigens scheint fujitsu beim Fugaka-Supercomputer die TofuD-Schnittstelle ("interconnect") zur Verbindung zwischen mehreren CPUs direkt in den Chip eingebaut zu haben, womöglich sogar so direkt, dass der Lichtleiter direkt am Chip ansetzt. Apple könnte etwas ähnliches machen und hätte dann einen Interconnect zur Verbindung mehrerer Rechner. Oder mehrerer CPUs in einem Rechner.
+2
ssb
ssb01.07.2016:01
Thyl
Wenn ich es richtig verstanden habe, hat ja intel für USB4 Thunderbolt freigegeben. Damit sinken möglicherweise die Kosten. Spannend finde ich auch die Idee, dass aufgrund der völligen Entwurfsfreiheit bei den eigenen Chips Apple die USB4/Thunderbolt-Controller direkt in das SoC integrieren könnte, womöglich sogar quasi ohne vorgeschaltetes PCIe. Signale sind zwar PCIe-Signale, aber vielleicht ist eine direktere Anbindung an den Prozessor auch möglich.

Übrigens scheint fujitsu beim Fugaka-Supercomputer die TofuD-Schnittstelle ("interconnect") zur Verbindung zwischen mehreren CPUs direkt in den Chip eingebaut zu haben, womöglich sogar so direkt, dass der Lichtleiter direkt am Chip ansetzt. Apple könnte etwas ähnliches machen und hätte dann einen Interconnect zur Verbindung mehrerer Rechner. Oder mehrerer CPUs in einem Rechner.

Das dürfte dann die Option für den Mac Pro werden. Ausreichend Steckplätze um zusätzliche CPUs mit Interconnect einbauen zu können, ggf. in einem eCPU-Gehäuse. Vermutlich fast unbezahlbar aber das wäre ein Killerfeature. Der Rechner wächst mit seinen Aufgaben.
+1
gfhfkgfhfk01.07.2017:19
ssb
Das dürfte dann die Option für den Mac Pro werden. Ausreichend Steckplätze um zusätzliche CPUs mit Interconnect einbauen zu können, ggf. in einem eCPU-Gehäuse. Vermutlich fast unbezahlbar aber das wäre ein Killerfeature. Der Rechner wächst mit seinen Aufgaben.
Nein, das wäre der Rohrkrepierer. Denn keine normale Software wäre mehr in der Lage die zusätzlichen CPUs zu nutzen. Die Interconnects in der Fujitsu Maschine wurden für MPI entwickelt, und auf Cluster ist das auch eine etablierte Methode Programme auf viele CPUs zu skalieren, auf dem Mac oder PC ist es das nicht.
+1
pünktchen
pünktchen01.07.2017:44
Es gibt beim Raytracing doch schon eine bewährte Methode den Rechner mit seinen Aufgaben wachsen zu lassen: mehr Grafikkarten reinstecken. Wenn man das Rad ein zweites Mal erfinden will müsste man schon darlegen wieso das nötig ist.
0
ssb
ssb01.07.2018:23
gfhfkgfhfk
ssb
Das dürfte dann die Option für den Mac Pro werden. Ausreichend Steckplätze um zusätzliche CPUs mit Interconnect einbauen zu können, ggf. in einem eCPU-Gehäuse. Vermutlich fast unbezahlbar aber das wäre ein Killerfeature. Der Rechner wächst mit seinen Aufgaben.
Nein, das wäre der Rohrkrepierer. Denn keine normale Software wäre mehr in der Lage die zusätzlichen CPUs zu nutzen. Die Interconnects in der Fujitsu Maschine wurden für MPI entwickelt, und auf Cluster ist das auch eine etablierte Methode Programme auf viele CPUs zu skalieren, auf dem Mac oder PC ist es das nicht.

Doch, im Grunde kann der Mach-Kernel genau das. Apple könnte das in Xnu (der Darwin Kernel) übernehmen und vom experimental Status in den Production Status bringen. Klar, ist viel Aufwand, aber Apple könnte das schaffen. Über GCD könnten auch gut programmierte Anwendungen das nutzen.
http://www.shakthimaan.com/downloads/hurd/kernel_princ iples.pdf
In general, the Mach kernel executes on a single machine, possibly a multiprocessor. Multiple such machines may be connected together in various ways, but this is the prov- ince of user space tasks. However, optional (and experimental) support is provided with- in the kernel for multicomputers, “machines” consisting of multiple multiprocessors (without shared memory between multiprocessors). Each uniprocessor or multiprocessor in such a multicomputer is called a node and referenced by a node ID (a number). The multicomputer as a whole is a Mach host.
Mach’s multicomputer support provides transparently distributed shared memory be- tween nodes and transparently distributed Mach IPC between nodes. The only direct op- erations supported by nodes are the setting and retrieving of a small set of node specific ports.
+1
piik
piik02.07.2001:16
Thyl
Wenn ich es richtig verstanden habe, hat ja intel für USB4 Thunderbolt freigegeben. Damit sinken möglicherweise die Kosten. Spannend finde ich auch die Idee, dass aufgrund der völligen Entwurfsfreiheit bei den eigenen Chips Apple die USB4/Thunderbolt-Controller direkt in das SoC integrieren könnte, womöglich sogar quasi ohne vorgeschaltetes PCIe. Signale sind zwar PCIe-Signale, aber vielleicht ist eine direktere Anbindung an den Prozessor auch möglich.
Das ändert aber nichts am Stromverbrauch, bzw. nur minimal. Schnelle serielle Leitungen schlucken einfach Energie. Wieviel kann ich nicht genau sagen, aber so 1-3W pro Schnittstelle sicherlich, also etwa soviel wie ein Core.
Thyl
Übrigens scheint fujitsu beim Fugaka-Supercomputer die TofuD-Schnittstelle ("interconnect") zur Verbindung zwischen mehreren CPUs direkt in den Chip eingebaut zu haben, womöglich sogar so direkt, dass der Lichtleiter direkt am Chip ansetzt. Apple könnte etwas ähnliches machen und hätte dann einen Interconnect zur Verbindung mehrerer Rechner.
Das ist mehr als Spekulatius. Macs sind PCs, keine Supercomputer. Solche Techniken kosten bloß und bringen nicht wirklich was für Desktop-Maschinen bzw. steht der Aufwand in keinem Verhältnis zum Nutzen. iMacs für 5-stellige Beträge und mehr kauft niemand.
+1
gfhfkgfhfk02.07.2009:26
ssb
Doch, im Grunde kann der Mach-Kernel genau das. Apple könnte das in Xnu (der Darwin Kernel) übernehmen und vom experimental Status in den Production Status bringen. Klar, ist viel Aufwand, aber Apple könnte das schaffen. Über GCD könnten auch gut programmierte Anwendungen das nutzen.
Hast Du jemals Software für NUMA oder MPP Systeme geschrieben?

Es geht nicht darum, dass der Kernel nicht in der Lage ist Software auf den CPUs auszuführen, sondern darum, dass der Entwickler innerhalb der Anwendung darauf achten muss, dass die Lokalität der Daten passt. Liegen die Daten auf einem anderen Knoten, braucht das sehr viel Zeit bis man darauf zugreifen kann. Sprich lässt man normale Software ohne Anpassung an das NUMA- bzw. MPP-System laufen, läuft sie bestenfalls gleich schnell oder sogar langsamer wie auf einem Knoten.

Auch Grand Central Dispatch ändern daran nicht viel, weil man für die optimale Auslastung solcher Systeme mehrere Hierachieebenen der Parallelisierung benötigt.
+3
ssb
ssb02.07.2012:36
Mal wieder ein Dislike, nur weil mal jemand, der sich mit dem Mach-Kernel beschäftigt hat, darüber nachdenkt, was möglich ist. Ob es sinnvoll ist, ist ein anderes Thema und ob Apple das zugänglich macht erst recht. Das ist einfach ein Gedankenspiel und Apple wird in der Riege der Supercomputer nicht mitspielen wollen.

Der Mach-Kernel stammt eben noch aus Zeiten, in denen die Rechenleistung von heute nur mit Computer-Clustern erreichbar war. Daher ist das konzeptionell enthalten, aber auch nur teilweise implementiert worden. Wenn der Kernel das könnte, dann könnte das OS das auch nutzen und es wäre zu erwarten, dass GCD das dann auch unterstützen würde, als User-Space API sozusagen. Das dann effizient zu verteilen ist Aufgabe des Schedulers, und natürlich ist es nicht einfach den Scheduler so zu programmieren, dass nur Tasks aus den GCD Queues an Prozessor-Sets eines anderen Nodes übergeben werden, bei denen dies effizient machbar ist. Am Ende müsste ein Software-Entwickler sich dann aber mehr um eine sinnvolle Nutzung von GCD in seinem Code kümmern, den Rest könnte der Scheduler im Kernel übernehmen. Zumindest auf diesen Punkt (effiziente Nutzung von GCD) verweist Apple in seiner Dokumentation immer wieder.

Aber das ganze ist eh Off-Topic.
+2
Thyl03.07.2010:04
piik
Thyl
Wenn ich es richtig verstanden habe, hat ja intel für USB4 Thunderbolt freigegeben. Damit sinken möglicherweise die Kosten. Spannend finde ich auch die Idee, dass aufgrund der völligen Entwurfsfreiheit bei den eigenen Chips Apple die USB4/Thunderbolt-Controller direkt in das SoC integrieren könnte, womöglich sogar quasi ohne vorgeschaltetes PCIe. Signale sind zwar PCIe-Signale, aber vielleicht ist eine direktere Anbindung an den Prozessor auch möglich.
Das ändert aber nichts am Stromverbrauch, bzw. nur minimal. Schnelle serielle Leitungen schlucken einfach Energie. Wieviel kann ich nicht genau sagen, aber so 1-3W pro Schnittstelle sicherlich, also etwa soviel wie ein Core.
Thyl
Übrigens scheint fujitsu beim Fugaka-Supercomputer die TofuD-Schnittstelle ("interconnect") zur Verbindung zwischen mehreren CPUs direkt in den Chip eingebaut zu haben, womöglich sogar so direkt, dass der Lichtleiter direkt am Chip ansetzt. Apple könnte etwas ähnliches machen und hätte dann einen Interconnect zur Verbindung mehrerer Rechner.
Das ist mehr als Spekulatius. Macs sind PCs, keine Supercomputer. Solche Techniken kosten bloß und bringen nicht wirklich was für Desktop-Maschinen bzw. steht der Aufwand in keinem Verhältnis zum Nutzen. iMacs für 5-stellige Beträge und mehr kauft niemand.
klar ist das spekulativ. Sollte Apple allerdings Mehrprozessorsysteme erwägen, so brauchen sie für die Verbindung zwischen den Prozesoren auch eine schnelle Schnittstelle, so wie das intel und AMD auch haben. Und speziell die Schnittstelle von AMD "Hypertransport" sieht sogar einen Stecker (HTX) vor, wobei der allerdings eher für Steckkarten, nicht zur Verbindung von Rechnern gedacht ist. Ist übrigens Industriestandard, könnte Apple also verwenden. Es ist also nicht so viel Mehraufwand, wenn man Mehrprozessorsysteme entwickelt, die Signale auch nach außen zu führen. Und das wird von Mach unterstützt, siehe Diskussion oben. Allerdings reicht natürlich ein Signalbus nicht aus, und dann wird alles etwas anspruchsvoller.
0
gfhfkgfhfk03.07.2011:48
ssb
Mal wieder ein Dislike, nur weil mal jemand, der sich mit dem Mach-Kernel beschäftigt hat, darüber nachdenkt, was möglich ist.
Es ist eben nicht möglich, weil das Betriebssystem nicht auf magische Art und Weise weiß, wie man Programme über mehrere Hierarchien sauber parallelisieren kann. GCD unterstützt auch keine Hierarchie bei der Parallelisierung. D.h. es spielt überhaupt keine Rolle, dass der Kernel in der Lage ist die Threads zu verteilen, die Applikation muss das steuern weil nur sie weiß wie die Lokalität der Daten aussieht, davon weiß der Kernel nämlich nichts, und GCD hat dafür in der API keinerlei Mechanismus, um den Kernel es zu übermitteln.

Irgendwie scheint mir hier, dass sehr viel Wunschdenken eine Rolle spielt. HPC Systeme wie das von Fujitsu werden nun einmal ganz anders programmiert als normale Desktops, was das Thema Parallelisierung betrifft. MPI und OpenMP sind hier die wichtigen Techniken, und man verknüpft die Knoten per Netzwerkfabric. Um die Systeme optimal zu programmieren, muss man sogar auf die Topologie der Fabric Rücksicht nehmen. Das führt dazu, dass man mehrere Ebenen der Parallelisierung hat:
  • Die Parallelisierung auf Core Ebene in einem einfachen Computer bzw. innerhalb eines NUMA-Knotens. D.h. die Cores teilen sich den gleichen Speicher, und meistens L3 oder L4 Cache. Nur L1 und L2 Cache sind lokal zu einem Core. D.h. es reicht hier aus, wenn man den Job so aufteilt, dass die verschiedenen Threads unterschiedliche Teile der Daten im Hauptspeicher bearbeiten, so kommt es zu keinen Konflikte und Synchronisationsproblemen zwischen den Threads. Da moderne Computer Cache kohärent sind, würden hier Fehler in einer Verlangsamung des Programm enden.
  • Die Parallelisierung auf NUMA-Knoten Basis. Damit sich die Knoten beim Speicherzugriff nicht in die Quere kommen, müssen die Daten zuerst auf alle beteiligten NUMA-Knoten kopiert werden, und nach dem Rechnen die Ergebnisse zurück kopiert werden. Achtet man darauf nicht, sind die Threads zwar in der Lage auf die Daten des Master-NUMA-Knotens zuzugreifen, aber sie bremsen sich so massiv aus, dass das Programm langsamer läuft als wenn es nur auf einem NUMA-Knoten läuft.
  • Auf die verschiedenen Cluster-Nodes muss man analog zur NUMA-Problematik die Daten auch explizit kopieren, nur hier gibt es keinerlei Möglichkeit auf den Master-NUMA-Knoten zuzugreifen, d.h. ohne explizites Kopieren passiert hier rein gar nichts.
  • In größeren Cluster gibt es nahe und ferne Cluster-Knoten, d.h. auch das muss man berücksichtigen, und da kann es auch mehrere Ebenen geben.
Je mehr komplizierter die Topologie wird, desto aufwendiger (mehr Latenz mehr Zeitbedarf) wird es die Jobs zu verteilen. Für die meisten Dinge in Desktopanwendungen braucht es mehr Zeit, sie in einem Cluster zu verteilen, als sie lokal auf einem NUMA-Knoten zu berechnen. Der Kopieraufwand ist beträchtlich und sollte keineswegs vernachlässigt werden. Gleiches gilt für die Synchronisation der Daten, d.h. auf einem Cluster läuft nur Software schnell, die wenig Synchronisation bedarf.
+2
ssb
ssb03.07.2014:30
Nun gfhfkgfhfk... das Gedankenspiel ging um Einen Multi-Rechner in einem Host, nahe und ferne Nodes sind da nicht relevant, und auch andere Dinge fallen da nicht so sehr ins Gewicht. Wie gesagt, Apple wir da keinen HPC-Cluster anbieten bzw, das anderen überlassen wie damals mit dem G5-basierten Supercomputer.

Was aber ginge wäre ein Rechner als Host der mehrere größtenteils selbstständige Nodes in Form von "Steckkarten" unterstützen könnte. Auch hierarchische Nodes sind kaum relevant, da die Ausbaufähigkeit sicherlich relativ enge Grenzen haben wird. Vielleicht Karten a 64 Cores und davon bis zu 4 Stück - nur mal als Beispiel. Für 4 Nodes plus Host braucht man noch keine Hierarchien, abgesehen vom Host als Master. Als Interconnect könnte da auch PCIe genutzt werden, oder eben etwas neues.

Wenn du dir die Specs von Mach noch mal anschaust, wirst du sehen, dass der Kernel für diesen Zweck Shared Memory Objects unterstützt über die die notwendigen Daten zwischen den Nodes ausgetauscht werden können.
Wenn du dir die Specs von GCD genauer anschaust wirst du sehen, dass auch dort an die Lokalität der Daten berücksichtigt wird und der Kernel kann das teilweise daran erkennen, wie die Daten im Source annotiert sind.

Immerhin können sich jetzt schon GPUs und CPUs in einem System den RAM teilen, Daten via PCIe austauschen während die GPUs relativ eigenständig sind. So weit ist das nicht von einem Multi-CPU-Set System entfernt. CLang/LLVM erzeugt dafür schon sehr guten Code.

Aber wie gesagt, es geht nicht darum ob es sinnvoll ist, darüber wird sich Apple den Kopf zerbrechen und sich dann überlegen zu welchem Preis ein solches System auf dem Markt eine Chance haben könnte. Vermutlich wären aber tatsächlich Rechner mit mehreren GPUs interessanter - weil die eh wesentlich schneller rechnen können.
+1
subjore03.07.2014:37
pünktchen
Metal unterstützt Raytracing.

Das macht es dann hoffentlich deutlich wahrscheinlicher, dass Apple das dann auch unterstützen wird. Wenn die jetzt dieses Jahr nur noch eigene Grafikkarten anbieten werden, dann sollten die das auch können. Ansonsten wäre es ja ein großer Rückschritt. Wobei ich etwas vermute, dass in Größeren Maschinen (großer iMac, 16" MacBook Pro und gerade MacPro) auch noch optional andere Grafikkarten möglich sind. Oder Apple hat ihre Grafikkarten auch so hoch skaliert, dass sie mithalten können. Das würde allerdings einen ganz anderen Aufbau verlangen, weil man ab einer gewissen Leistung CPU und GPU nicht mehr auf einen Chip vereinen kann.
0
gfhfkgfhfk03.07.2016:28
ssb
Aber wie gesagt, es geht nicht darum ob es sinnvoll ist,…
Doch genau darum geht es mal wieder, wenn hier die große Märchenstunde anbricht. Man kann eben nicht so einfach irgend eine Karte in das System stecken, mehr CPUs im System integrieren o.ä. und dann skaliert Software mal eben so darauf. Das ist schlicht unwahr.

Es bedarf umfangreicher Änderungen an der Software, und Apple hat die NUMA MacPros (nur 4,1 und 5,1) aus diesem Grund eliminiert, weil man sich mit dieser Problematik nicht mehr beschäftigen wollte.
-2

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.