kann ich aus der sicht von frontier developments sehr gut verstehen.

Richtig so. Alte Zöpfe abschneiden.

Du Schelm

Nun Metal am Mac, im Gegensatz zu iPhones ist halt wenig interessant für die Devs. Speziell Devs die nicht Mac Only entwickeln werden mit Directx, OpenGL und Vulkan schon ausreichend zu tun haben das zu programmieren. Zudem hat Metal speziell bei schwächeren CPUs mehr Vorteile wie bei Highend CPus (in Macs, Hackintoshs) - dort erzielt Metal , weil es vorallem CPU Zeit spart (CPU Zeit die ohne Metal im OpenGL Treiber verbraten wird), am meisten Wirkung.
Für Macs wäre es weit wichtiger, dass Apple mal die OpenGL (4,1 vs. 4,3/) und OpenCL (1.2 vs 2.2!) Treiber aktualisiert und optimiert statt mit Metal - da sind sie noch am Anfang - wiede was neues zu bringen. Denn die Apple Devs können nun mal nicht parallel alls auf einmal machen. Da Metal vorallem für iPhones/iPads wichtig ist und diese wiederum für Apple wichtiger wie Macs ist verständlich aber Mist wenn man mit iPhones nix am Hut hat.

So eine Firma wie Apple welche kaum Gewinne einfährt und immer knapp vorm Bankrot steht, hat es schwer genügend Ressourcen für die Weiterentwicklung von diversen Schnittstellen bereitzustellen. Da muss man sich schon auf wesentliche Sachen beschränken

Ich weiss nicht wieso Apple nicht OpenGL und Metal zur Verfügung stellen kann. Wenn sie meinen den Entwicklern da ihren Willen aufzwingen zu können dann verkennen sie die Machtverhältnisse. Sind halt kein Monopolist wie MS mit Windows.

Die Zeiten von OpenGL sind doch vorbei … Abseits von DirectX sollte die Spielezukunft eigentlich bei Vulkan liegen, jedoch scheint es, dass manche Devs da auch schon weniger Lust darauf haben.
Der Grund warum Apple auf Metal setzt dürfte iOS sein, da Schnittestelle aber natürlich auch auf macOS läuft, wird das halt forciert.
Im Prinzip ist das auch nicht schlimm, sie, oder besser gesagt wir, müssen uns halt dann damit leben, dass manche Spiele nicht mehr portiert werden.

Nachdem die Erweiterung Horizons genau wegen der compute shaders schon nicht für macOS kam, war das schon vorhersehbar. Naja, muss ich halt Windows auf dem iMac starten, um Elite Dangerous spielen zu können. Ist mit VoiceAttack und anderen kleinen Helfern auch eine angenehmere Erfahrung.
Ich verstehe nur Apple hier nicht. Warum macht man hier was eigenes, was eigentlich auch gut mit Vulkan abgedeckt werden könnte? Hat man immer noch nicht kapiert, dass eine eigene Soße Entwickler nur abschreckt? Ja, cool, da entwickeln jetzt ein paar mit Metal, aber der größte Teil bleibt weg, weil die ihre Spiele auf allen Plattformen anbieten wollen und nicht noch elendig lang schuften müssen, nur um den absolut kleinen Markt von Apple-Gamern noch abzudecken... Ja sorry, zu Hause spiele ich inzwischen mehr mit meinem Computer, also werde ich bei meinem nächsten Computer mir wohl stark überlegen, ob es nicht doch ein Windows-Gerät gibt, und die nächsten 2000€ halt bei einer anderen Firma landen... Schade, gell?

Vielleicht weil Metal bereits 2014 auf iOS und 2015 auf macOS kam, Vulkan 1.0 aber lt. Wikipedia erst 2016?

Das Gros der Spiele wird eigentlich nicht von den ursprünglichen Entwicklern nach macOS portiert. Es sind Firmen wie Aspyr, Feral usw, die das machen und die können sehr gut mit Metal umgehen

Ich denke Apple wird's verkraften.

Vor allem weil es ausser Spielen auch noch jede Menge Pro Anwendungen gibt, die auf Open GL setzen. Wenn es irgend ein Spiel nicht für Mac gibt, wechseln ich deswegen nicht gleich die Plattform. Wenn dagegen meine Brot- und Butter Animationssoftware nicht mehr läuft, bleibt mir aber gar nichts anderes übrig.

OpenGL 4.6 ist der aktuelle Stand.

Allerdings. Für Firmen wie Maxon muss es ziemlich bitter sein für ihr cross platform-Bekenntnis in einer uralt Grafikbibliothek gefangen zu sein, während z. B. Autodesk immer aktuelle Schnittstellen geliefert bekommt.

Wobei ich auch nicht verstehe wieso AMD, NVidia & Intel nicht für macOS aktuelle Treiber liefern können genau wie sie es für Windows und Linux auch machen. Gibt es da irgendwelche technischen Gründe?

Apple braucht in Metal keine Compute Shaders, da jedes macOS, das Metal unterstützt, auch OpenCL unterstützt und OpenCL kann schon seit Jahren das, was Compute Shaders können, nämliche beliebige Berechnungen auf der GPU ausführen und ist dabei viel mächtiger als Compute Shaders. Das schöne an OpenCL ist, dass man dort nur die Berechnung spezifiziert und sich dann zur Laufzeit aussuchen kann, ob die Berechnung auf der GPU, der CPU oder irgend einer anderen OpenCL Compatiblen Recheneinheit ausgeführt werden soll. Das kann man also dynamisch entscheiden, wenn mal will sogar bei jeden Aufruf anhand der Auslastung (Mal sehen... die GPU ist gerade total ausgelastet, aber die CPU hat Luft, gut, dann macht das jetzt die CPU, sonst ruckelt das Bild; beim nächsten mal ist die CPU vielleicht am Anschlag, aber es wird gerade kaum was gezeichnet, dann macht es da eben die GPU).

OpenCL ist viel mächtiger und viel flexibler, konnte sich bisher nur nicht mal wieder auf den anderen Plattformen durchsetzen (bei Windows ist es mal wieder Microsoft, die sich sperren und daher muss man dort erst mal OpenCL Treiber installieren, was kein Mensch tut und bei Linux, ach lassen wir das). Aber das könnte sich bald ändern, da OpenCL ein fester Teil von Vulkan werden soll und dann auf allen Plattformen mit Vulkan verfügbar wäre, also auch Windows und Linux. Und Vulkan und Metal sind im Prinzip das Gleiche, sie arbeiten konzeptionell identisch. Daher gibt es ja einen Vulkan Wrapper für Metal. Auf der Programmseite programmierst man einfach Vulkan, wie auf jeder anderen Plattform auch, und intern wandelt die das um in Metal Befehle, wie gesagt, die APIs sind sich extrem ähnlich von der Arbeitsweise, da sie sich beide einfach an der Hardware orientieren, sie sind so aufgebaut wie moderne GPUs heute auch wirklich arbeiten.

Ganz im Gegensatz zu OpenGL, das so entworfen wurde, wie früher mal GPUs gearbeitet haben, nur die arbeiten schon lange nicht mehr so und müssen für OpenGL oft altes Verhalten emulieren bzw. OpenGL wurde deswegen auch schon zigfach umgebaut und aufgebohrt und ist nur noch ein total unübersichtlicher Haufen an API Aufrufen, die kein Gesamtkonzept mehr erkennen lassen und die nicht mehr mit dem ursprünglichen Design dieser API zu tun haben. OpenGL war gedacht für echte Grafikeinheiten, denen man 3D Daten und Texturen gibt, welche beide von der GPU verarbeitet, transformiert, gefiltert, usw. und dann auf den Bildschirm gezeichnet werden. Aber heutige Grafikkarten sind einfach wie kleine PCs: Sie haben eine CPU (auch wenn die GPU heißt und anderen Dinge kann als normale CPUs), sie haben RAM und sie führen Programmcode aus um Daten aus diesem RAM irgendwie zu verarbeiten. Den Code kannst du selber programmieren und sie damit eigentlich beliebige Dinge tun lassen, die rein gar nichts mehr mit Grafik zu tun haben und dafür war OpenGL aber nie ausgelegt. Dafür gab es eigentlich OpenCL.

Nur nVidia liefert für macOS die Treiber selbst, für die AMD und Intel Treiber ist Apple verantwortlich, und Apple bestimmt für alle welche OpenGL Version unterstützt wird.
Mit OpenCL sind aber keine Grafikdarstellungen möglich, sprich OpenCL taugt nur für Rechnungen.
OpenCL unter Linux ist de facto überflüssig, da es für optimalen Code nicht portabel ist, d.h. man muss immer OpenCL für AMD und nVidia anpassen.

CUDA ist älter und bietet Support für die stärkste GPGPU-Plattform, so dass es wenig Sinn ergibt sich mit OpenCL auseinander zu setzen, denn CUDA unterstützt die nVidia GPGPUs sehr viel besser. Allein der Softwarestack für CUDA ist dramatisch besser. Die Abstraktion für die Plattformen erfolgt nicht auf Basis von OpenCL vs. CUDA sondern eine Ebene höher, d.h. BLAS auf OpenCL AMD vs. BLAS CUDA vs. BLAS auf OpenMP.

Ich weiss - aber wieso ist das so? Klar NVidia muss selbst ran weil Apple ihre GPUs gerade nicht verbaut und daher auch keine Treiber programmiert, aber auch AMD und Intel könnten doch eigene Treiber liefern.

Apple liefert die OpenGL API und da können die Hersteller nichts dran ändern, sie können nur einen Treiber liefern, der das API Level von Apple auf den Karten umsetzt.

Unter Linux (und diverse andere OS) ist MESA 18.0.x stable und das unterstützt nur OpenGL 4.5. nVidia ersetzt den OpenGL Stack durch eine neuere Version, so dass OpenGL 4.6 unterstützt wird. Das geht, weil die Sourcen zu MESA frei erhältlich sind und nVidia binärkompatible Versionen selbst herausgeben kann.

Wer bitte hat auch derartiges jemals behauptet? Für Grafik nimmt man Metal oder Vulkan. Es ging hier darum, warum Apple keine Compute Shaders kennt. Alle anderen Shaders bietet Metal dir ja und die Vulkan Layer kann sogar Vulkan Shader in Metal Shader übersetzen, ergo sind diese beiden APIs sogar bei Shadern noch austauschbar und auch hier ist der Grund, dass diese APIs nicht einfach etwas vorgeben und GPU Hersteller müssen das umsetzen, sondern sie wurden anhand dessen entworfen, was GPUs heute von Haus aus schon mitrbingen und können.
CUDA is proprietärer Nvidia Kack. OpenCL wird explizit auf der Wikipedia Seite von CUDA als "alternative GPGPU" Lösung genannt. Genauso wie Compute Shaders in Vulkan.

Wenn Frontier Developments Elite Dangerous weiterhin am Mac hätte unterstützen wollen, dann wäre das problemlos gegangen. Statt OpenGL, dass heute sowieso nur noch dazu dient Daten und Shader zu laden um dann Daten durch Shader zu jagen, hätten sie einfach Metal nehmen können (das kann das auch alles, viel einfacher, besser und schneller), oder gleich Vulkan (weil das werden sie auf anderen Plattformen sowieso langfristig nutzen) und am Mac den freien Meta-Vulkan Wrapper. Selbst mit dem Vulkan Wrapper erreicht man im Schnitt am Mac die doppelte Framerate wie mit OpenGL. Und ihre tollen Compute Shader Berechnungen hätten sie am Mac einfach mit OpenCL machen können und fertig.

Im Grunde ist das hier nur Mimi und übersetzt sich zu:
"Der Mac arbeitet nicht so wie, wie wir das gerne hätten und jetzt müssten wir 2% mehr Arbeit extra für Mac User investieren und das sind uns die Mac User einfach nicht wert, adiós Mac User. Aber natürlich lässt uns das wie einen Haufen A-Löcher da stehen, also schnell mal irgend ein doofe Ausrede finden und die Schuld auf Apple abwälzen; der Durchschnittsnutzer hat eh keine Ahnung wovon wir hier reden, woher sollte der also wissen, dass das natürlich problemlos möglich ist und wir einfach nur zu faul sind?"

Und die API ist so tief ins macOS integriert dass man nicht einfach durch zB Mesa ersetzen kann, richtig?

macOS nutzt die GPU schon ewig um die Darstellung der Desktop UI und Fenster zu beschleunigen. Früher haben die dafür direkt auf OpenGL aufgesetzt, heute vielleicht nur noch auf Metal oder beides. Die Anbindung an die 3D Schnittstelle ist also tief im Grafiksubsystem von macOS verwurzelt, sie ist quasi das Grafiksubsystem geworden, und das Grafiksubsystem ist ein in sich geschlossene Einheit.

"Ersetzen" kannst du unter macOS grundsätzlich schon mal nichts. Zum einen erlaubt macOS seit 10.11 gar nicht mehr, dass bestimmte Dateien nach dem Boot angefasst werden () und zum anderen sind Komponenten oft nur Unterkomponenten einer anderen Komponenten und würdest du da einfach was austauschen, dann brichst du die Signatur der umschließende Komponente und das war's dann. Du kannst nicht ersetzen, nur ergänzen, dort wo Apple Explizit vorsieht, das man ein bestehendes System erweitern kann. Und es ist schlichtweg nirgendwo in macOS vorgesehen, dass du fundamentale System APIs (also APIs, ohne die macOS gar nicht mehr lauffähig wäre) umbauen oder erweitern kannst, denn macOS sieht sich nicht als ein Bastelsystem und versucht den Nutzer auch vor seiner eigenen Unwissenheit zu schützen (kann ja sein das deine tolle API Erweiterung, die du da gerade installierst, in Wahrheit ein Trojaner ist).

Apple sieht einfach keinen Grund OpenGL weiter zu pflegen. OpenGL hat keine Zukunft. Mit Metal haben sie ein API am Start, die absolut ebenbürtig zu Vulkan oder dem neusten Direct3D in Windows ist. Und mit OpenCL haben sie eine API, die viel mächtiger als Compute Shader ist, wenn es darum geht etwas auf der GPU zu berechnen. macOS bringt alles mit was dieses Spieleentwickler brauchen würden, ihnen passt es nur nicht, dass sie ihren OpenGL Code, den sie für andere Plattformen geschrieben haben, nicht eins zu eins einfach so am Mac nutzen können, das ist schon alles. Dabei ist es nur eine Frage der Zeit, bis auch die OpenGL ganz aufgegeben werden, einfach da moderne APIs mit der gleichen GPU doppelt so gute Frameraten erzielen, bzw. bei gleicher Framrate doppelt so viele Objekte zeichnen könnten.

Das ist ja alles schön und gut nur nutzt das nichts wenn man ein Programm portieren möchte welches Funktionen von OpenGL 4.5 nutzt. Der Ratschlag doch bitte Metal zu verwenden ist etwa so hilfreich wie der statt C++ doch bitte Swift zu verwenden.

Der proprietäre Kack hat sich aber in Bereichen wie GPU Rendering zum Standard entwickelt. Wie kommts?

Was bitte verstehst du unter Portierung? Code von Plattform A einfach eins zu eins für Plattform B zu übernehmen ist keine Portierung; wo bitte soll dabei die Portierung gewesen sein? Portierung heißt man nimmt Code von Plattform A und passt ihn an Plattform B an. Und wenn Plattform B kein OpenGL 4.5 aber eine vergleichbare API bietet, dann ist genau dieser Umbau das, was man gemeinhin als Portieren bezeichnet. Ich kenne Spiele aus der pre-Shader Zeit, die nutzen unter Windows Direct3D und unter Linux OpenGL und diese beiden APIs sind sich nicht mal im Ansatz ähnlich gewesen zu dieser Zeit.

Wie machen die denn Sound? macOS unterstützt keine der Sound APIs die man unter Windows oder Linux finden würde und umgekehrt findest du die macOS APIs auch nur am Mac. Da konnten die auch nicht einfach den gleichen Code nehmen. Und wie ich bereits gesagt habe, 95% aller OpenGL Funktionen werden heute nicht mehr benutzt, weil das alles Funktion aus der pre-Shader Zeit sind, die braucht man nicht mehr bzw. selbst wenn man die nutzen würde, dann emulieren neue GPUs die nur über Shader im Treiber, weil die das auch schon lange nicht mehr in Hardware können.

Heute machen Shader einfach alles, den sie sind schneller, effizienter, flexibler und nach belieben anpassbar. Heute wird OpenGL nur noch dazu genutzt Daten in den GPU Speicher zu laden (3D Daten, Texturen, Shader), dann einen Shader Run vorzubereiten (Shader aktivieren, Eingabeparameter festlegen, Output Buffer festlegen, usw.) und dann die Shader laufen zu lassen. Mehr passiert da nicht mehr. Und das alles sind nur wenige Aufrufe und für jeden dieser OpenGL Aufruf gibt es eine funktionell äquivalenten Metal Aufruf (nur das die API um Welten schöner ist und der Code danach noch lesbar sein wird).

Und auch C++ Code nach Swift zu portieren ist das, was man portieren nennt. Auch ein Sprachwechsel ist normale Portierarbeit. So hab ich mal für eine Firma eine App von iOS nach Android portiert, iOS was die App natürlich Objective-C, Android natürlich Java. Das nennt sich portieren. Und das ist eine sehr einfache, aber leider auch recht langweilige, stupide Arbeit, weil sie keine große Denkarbeit erfordert. Du musst dir ja nichts neues Ausdenken, keinen Lösung für ein Problem finden, denn es wurde bereits alles ausgedacht und gelöst, du hast die Lösung schon vor dir. Ist wie einen Text von Deutsch nach Englisch übersetzen, der Text ist ja schon da, du musst dir nicht erst einen Geschichte oder eine Artikel ausdenken, den gibt es ja schon, du musst ihn nur stupide übersetzen. Ich könnte niemals einfach so loslegen und 3D Code schreiben, da fehlt mir die Erfahrung und Übung, aber zeig mir 3D OpenGL Sample Code und ich mach dir Metal Code daraus, das ist kein großes Problem und höchstens zeitaufwendig, aber nicht schwierig.
Hat er nicht. Niemand außer Nvidia unterstützt CUDA (und nur mit Nvidias eigenen Treibern). Damit das Zeug auf anderen Karten überhaupt läuft, wird es in OpenCL, OpenGL oder Direct3D umgewandelt und diese Umwandlung ist eher minderwertig, daher können natürlich Nvidida Karten hier immer glänzen. Das dient nur dazu die Konkurrenz schlechter aussehen zu lassen als sie in Wahrheit ist.

Siehe auch Wikipedia : Das inzwischen auf Vulkan/SPIR-V abgestützte OpenCL ist universeller und bietet eine Implementierung für GPUs von Nvidia, AMD (vormals ATI), VIA, S3 und Anderen. Und wenn Microsoft so wie Apple einfach immer schon OpenCL oder ein halbwegs aktuelles OpenGL angeboten hätte (und nicht nur 2.2!), dann hätten Entwickler einfach das genommen und CUDA links liegen gelassen, aber Microsoft hat hier gar nichts angeboten (Direct3D konnte das nicht), nur deswegen konnte CUDA bei Windows Games einen kurzen Hype erleben, der schon längst am abebben ist.

Wie ich weiter oben schon schrieb, spreche ich nicht von Games. Ich spreche von professionellen GPU Renderern, wie zB Octane oder Redshift . Es gibt zwar zB auch das AMD eigene, OpenCL basierte Pro Render - aber im Vergleich zur CUDA Konkurrenz ist das nicht mal ein Spielzeug, da hinkt AMD in der Entwicklung mindestens fünf Jahre hinterher.

Als MacUser habe ich ja selber lange Zeit gehofft, das irgendwann Octane für OpenCL kommt aber offensichtlich hat sich in diesem Bereich CUDA - Verzeihung: dieser proprietäre Kack - auf ganzer Front durchgesetzt. Daher meine Frage: woher kommts?

OpenCL auf dem Mac ist Uralt:
Mac-Unterstützung:
Versionshistorie OpenCL:

Kurz zusammengefasst: Im besten Fall hat man den Stand von OpenCL aus 2011. Die Updates für OpenCL aus 2013, 2015 und 2017 gibt's auf dem Mac nicht.

OpenGL ist eher „high level” während Volkan im „low level”-Bereich der APIs angesiedelt ist. Dadurch gibt es unterschiedliche Verwendungszwecke für die beiden APIs. Vulkan und OpenGL sollen laut Khronos Group weiterentwickelt werden.

WebGL basiert auf OpenGL ES 3.0, welches wiederrum dann irgendwie mit OpenGL zusammenhängt .
Die Features in Metal sind nicht deckungsgleich mit denen von Vulkan und in MoltenVK als Übersetzungslayer fehlen Funktionen:
Fazit:

• Browser auf dem Mac bekommen bei neuen WebGL-Versionen Probleme mit der Kompatibilität bekommen.
• OpenCL ist für Berechnungen nur ein eingeschränkter Ersatz, da auf dem Mac veraltet.
• Plattformübergreifende Programme werden ggf. die Mac-Unterstützung streichen, wenn die Grafikunterstützung nur weiterentwickelt wird statt die benutzte API mehr oder weniger komplett auszutauschen. Davon betroffen könnten z.B. Spiele, aber auch die CAD-Programme sein.

CUDA ist gerade im technischwissenschaftlichen Bereich die einzige Möglichkeit mit vertretbaren Aufwand GPGPU-Programme zu schreiben. nVidia liefert sehr viele hochwertige Entwicklerwerkzeuge und Bibliotheken mit und verringert den Aufwand erheblich. Ähnlich macht das Intel. Nur HPC auf Intel heisst OpenMP und nicht OpenCL. OpenCL ist nur für AMD GPGPUs sinnvoll und sonst sollte man die Finger davon lassen, weil man nämlich auch für nVidia prorpietäre nVidia OpenCL Programme schreiben muss und dann kann man gleich das deutlich bessere CUDA nutzen.

Und auf einer Intel MIC Karte programmiert man ebenfalls nicht mit OpenCL, da nutzt man wie auf den normalen Intel und AMD CPUs OpenMP.

Nein, die Konkurrenz (AMD) ist so schlecht. Für Intel bekommt man brauchbare Werkzeuge und Bibliotheken, muss aber anstatt OpenCL OpenMP nutzen. OpenCL auf einer XeonPhi ist unsinnig. Dazu ist OpenMP Code relativ problemlos auf allen Intel CPUs lauffähig und nicht nur auf den XeonPhis.

Die BSD API ist sogar noch viel, viel älter... und was soll das jetzt aussagen? Sofern du nicht auf eine neue Funktion angewiesen, spielt das Alter einer API keine Rolle, vor allem da es Null über das Alter der Implementierung aussagte, sondern nur auf welchen Stand die Schnittstelle ist. OpenAL ist auch uralt, weil es nicht mehr weiter entwickelt wird, aber es ist an sich auch featuer complete und wenn man es heute nutzt, funktioniert es so gut wie eh und je. Und, ohne zu wissen um welche Berechnungen es konkret geht, die Behauptung aufzustellen, dass sich das mit OpenCL nicht umsetzen lässt am Mac, das OpenCL zu alt dafür ist, halte ich für eine sehr gewagte These.
Das kann man so nicht sagen. Im Grunde gab es alles was Vulkan heute kann zuvor auch schon als Teil eines OpenGL Standards oder zumindest als eine OpenGL Erweiterung (ARB oder Vendor). Auch ist Vulkan auch nicht wirklich low-leveliger von den Konzepten her (Texturen, 3D Daten und Shader). Es ist viel mehr so, dass wenn man heute alles aus OpenGL herauswirft, dass GPUs schon lange nicht mehr in Hardware können, sondern das man heute nur noch über Shader oder direkt in Software emuliert werden muss, dann bleibt im Grund das Funktionsset von Vulkan übrig. Der einzige, echte Unterschied der beiden ist, dass Vulkan ein Threading Konzept besitzt, während OpenGL eigentlich für Single Thread Zugriff ausgelegt worden ist und sich nur bedingt mit mehren Threads zeitgleich sinnvoll nutzen lässt. Ansonsten ließe sich OpenGL problemlos auf der Basis von Vulkan implementieren, außer ein paar ganz exotischer Vendor Extensions, aber die beherrschen eh nur Karten bestimmter Hersteller, dass diese also vorhanden sind, darauf kann und darf sich ein Entwickler nie verlassen.
"Basiert auf" heißt aber nicht ist featuredeckungsgleich. OpenGL ES 2.0 basierte auch auf einen OpenGL 2.0, aber dennoch werden diverse OpenGL 2.0 Features nicht unterstützt und umgekehrt bietet OpenGL ES 2.0 Features, die teilweise erst mit OpenGL 4.1 auch am Desktop eingeführt wurden und manche gibt es dort bis heute nicht. Ansonsten ist WebGL nur eine API Schnittstelle für JavaScript und sagt rein gar nichts darüber aus, wie ein Browser diese implementiert. Eine WebGL Implementierung kann auch auf Vulkan oder Metal basieren, sie muss sich nur so verhalten, wie der WebGL Standard es sagt.
Das MoltenVK nicht alle Features unterstützt heißt nicht, dass sie nicht Deckungsgleich sind, du weißt ja gar nicht warum diese nicht existieren. So bietet MoltenVK nach eigener Aussage nichts an, was sich nur durch "einfachstes Mapping" erreichen lässt, sondern wo z.B. Daten konvertiert werden müssten. D.h. dann aber nicht, dass es nicht auch möglich wäre diese Funktionen abzubilden, halt mit etwas Processing dazwischen, denn manchmal sind die selben Funktionen schon vorhanden, nur die Datenformate unterscheiden sich geringfügig. Durch das "Processing" hätte man keinen "nativen Speed" und daher wird das derzeit nicht angeboten, aber du musst ja kein MoltenVK nehmen, du kannst ja selber abstrahieren mit einer Zwischenlayer, die dann wahlweise OpenGL, Vulkan, Metal oder Direct3D nutzt. So machen das alle Entwickler von 3D Engines schließlich auch. Ich habe nicht gesagt irgendwer muss MoltenVK nehmen, vielmehr ging es hier um den Beweis, dass es möglich ist Vulkan über Metal nachzubilden (und demnächst bildet MoltenVK auch Vulkan über Direct3D nach). Und fehlende Features spielen auch nur dann eine Rolle, wenn dieses Feature überhaupt von deinem Code genutzt wird und wenn es darüber hinaus wichtig oder unverzichtbar ist. Auch diese Annahme von dir ist schon wieder völlig aus der Luft gegriffen.