Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › WebGPU: Apple stellt moderne 3D…

Das ist wohl ein schlechter Scherz!

Anzeige
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Das ist wohl ein schlechter Scherz!

    Autor: pythoneer 08.02.17 - 19:08

    >The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms.

    Ja, sehr "unfortunately" das keine API davon auf allen Plattformen läuft, nicht wahr Apple? Ich frage mich was da wohl der Grund für ist? Liegt bestimmt daran, dass Khronos Apple verbietet, Vulkan auf macOS/iOS zur Verfügung zu stellen. Das kann ja wohl nicht deren ernst sein! Ich meine können sie ja machen, zwingt sie ja keiner Vulkan zur Verfügung zu stellen – sich dann aber hinzustellen und so ein "unfortunately" von sich zu geben ist ja wohl ziemlich geheuchelt!

    Ich hoffe dieser U-Boot Versuch hier (web)Metal populär zu machen geht gehörig nach hinten los. Wisst ihr was noch ziemlich "unfortunately" ist? Das OpenGL auf macOS mittlerweile fast 7 Jahre hinterher hingt und das letzte mal als ich geguckt habe gab es auch noch keine HD Audio Formate wie Dolby True HD oder DTS-HD Master Audio so dass ich auch mal Dolby Atmos oder DTS:X von nem Apple Gerät auf meinem Denon AVR abspielen kann. Technology von 2008 ... Blu-Ray (aber davon hat Apple auch noch nix gehört)

    "unfortunately" ... also echt!

    Linux is highly user friendly, it is just highly selective who it is friends with.

  2. Re: Das ist wohl ein schlechter Scherz!

    Autor: Panzergerd 08.02.17 - 19:26

    WebM, ein Videoformat das auf vielen Imageboards verwendet wird, können sie auch immer noch nicht.

  3. Re: Das ist wohl ein schlechter Scherz!

    Autor: /mecki78 08.02.17 - 19:39

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Liegt bestimmt daran, dass Khronos Apple verbietet, Vulkan auf macOS/iOS
    > zur Verfügung zu stellen.

    Nein, das liegt exakt daran, dass niemand Vulkan für MacOS implementiert.

    Warum Apple das nicht macht? Warum macht es denn Microsoft nicht für Windows? Es gibt Vulkan für Windows, aber das kommt schließlich auch nicht von Microsoft. Also warum wird von Apple immer das gefordert, was Microsoft z.B. noch nie gemacht hat?

    Und was ist schlecht daran, wenn ein Webstandarad eben nicht auf X oder auf Y basiert, sondern so neutral ist, dass es letztlich auf allen möglichen basieren kann, sogar auf OpenGL (auch wenn er dann natürlich nicht die großartige Performance haben wird). Ich würde deine Kritik verstehen, wenn das quasi Metal wäre und auch nur mit Metal funktionieren würde, aber dem ist ja nicht so. Vulkan und sogar Direct3D waren von Anfang an als mögliche Unterbauten vorgesehen. Damit ist das besser als WebGL jemals war, weil das sah genau nur OpenGL als Unterbau vor (und das auf z.B. Direct3D abzubilden ist in etwa so, als ob man gleich ganz OpenGL über Direct3D abbildet und dürfte sehr schlechte Performance liefern).

    Jetzt wird Apple schon kritisiert dafür, dass sie es wagen offene Standards zu schaffen, nur weil sie nicht auf dem Standard setzten, den du persönlich toll findest. Wer bitte sagt, dass Vulkan so toll ist oder das es die beste 3D API überhaupt ist? Kennst du dich überhaupt mit 3D APIs aus? Weißt du überhaupt wie sich Vulkan, Direct3D und Metal unterscheiden? Hast du schon mal mit allen drei gearbeitet? Und wenn nicht, woher willst du dann wissen das Vulkan so toll ist?

    Weil es das für mehr als eine Plattform gibt? Das alleine macht es noch lange nicht toll. Die APIs selber, Direct3D und Metal, wären genauso portabel auf alle Plattformen, gemeint ist hier nicht der Code, sondern die Schnittstelle. Denn viel mehr als die Schnittstelle wird bei Vulkan auch nicht portiert, denn der Rest ist natürlich in weitein Teilen plattformabhängig und damit nicht portierbar, denn anders als OpenGL macht Vulkan ja selber fast nichts mehr; Vulkan soll ja nur noch einen ganz dünne Layer zwischen der App und dem Grafikkartentreiber (und damit der GPU selber) sein. Ergo ist da auch nicht viel Code. Der Code beschränkt sich darauf von der App Anweisungen entgegen zu nehmen und die in etwas zu übersetzen, dass der Grafikkartentreiber versteht (der dass dann wiederum in etwas übersetzt, dass die GPU selber versteht) und natürlich sind Grafikkartentreiber auf jeder Plattform anders und auch ganz anders in das System eingebunden, ergo gibt es da nichts, was man groß portieren könnte.

    /Mecki

  4. Re: Das ist wohl ein schlechter Scherz!

    Autor: gaciju 08.02.17 - 20:09

    Panzergerd schrieb:
    --------------------------------------------------------------------------------
    > WebM, ein Videoformat das auf vielen Imageboards verwendet wird, können sie
    > auch immer noch nicht.


    MS uebrigens auch nicht.

  5. Re: Das ist wohl ein schlechter Scherz!

    Autor: QDOS 08.02.17 - 20:10

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Warum Apple das nicht macht? Warum macht es denn Microsoft nicht für
    > Windows? Es gibt Vulkan für Windows, aber das kommt schließlich auch nicht
    > von Microsoft. Also warum wird von Apple immer das gefordert, was Microsoft
    > z.B. noch nie gemacht hat?
    Der Unterschied ist: MS hat auch nie OpenGL 1.2 oder höher angeboten und vermarktet seit jeher DirectX (respektive Direct3D) als offizielle API.

    Apple hingegen bot bis vor kurzem offiziell nur OpenGL als offizielle 3D-API an und lieferte die (veraltete) Implementierung AFAIK selber...

  6. Re: Das ist wohl ein schlechter Scherz!

    Autor: gaciju 08.02.17 - 20:27

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Nein, das liegt exakt daran, dass niemand Vulkan für MacOS implementiert.

    Falsch. AMD, Intel und ImgTec wuerden liebend gern ihre Vulkan Treiber auch unter MacOS und iOS bereitstellen.

    > Warum Apple das nicht macht? Warum macht es denn Microsoft nicht für
    > Windows? Es gibt Vulkan für Windows, aber das kommt schließlich auch nicht
    > von Microsoft. Also warum wird von Apple immer das gefordert, was Microsoft
    > z.B. noch nie gemacht hat?

    Apple liefert die Treiber fuer MacOS (und iOS sowieso) selber mit aus, Microsoft nicht. Windows hat keine d3d Beschleunigung an Bord. Das wird ueber Grafikkartentreiber nachinstalliert, wenn auch automatisch ueber Windows Update.

    > Und was ist schlecht daran, wenn ein Webstandarad eben nicht auf X oder auf
    > Y basiert, sondern so neutral ist, dass es letztlich auf allen möglichen
    > basieren kann, sogar auf OpenGL (auch wenn er dann natürlich nicht die
    > großartige Performance haben wird). Ich würde deine Kritik verstehen, wenn
    > das quasi Metal wäre und auch nur mit Metal funktionieren würde, aber dem
    > ist ja nicht so.

    Doch, dem ist eben genau so. Das was Apple bisher vorgelegt hat, ist nichts anderes als Metal + JavaScript. Und wie sich in der Diskussion herausstellt, ist es auch genau das, was sie am Ende haben wollen. Hauptsache sie haben keine Arbeit, alle anderen duerfen aber zusaetzlich eine voellig neue Schnittstelle mit 2-3 neuen Backends implementieren.

    > Vulkan und sogar Direct3D waren von Anfang an als mögliche
    > Unterbauten vorgesehen. Damit ist das besser als WebGL jemals war, weil das
    > sah genau nur OpenGL als Unterbau vor

    Auch das ist falsch. WebGL basiert auf GLES.

    > ist in etwa so, als ob man gleich ganz OpenGL über Direct3D abbildet und
    > dürfte sehr schlechte Performance liefern).

    Du wirst lachen, aber Mozilla und Google verwenden fuer ihre Browser ANGLE, was WebGL/GLES auf d3d mappt, weil es idR. besser performt.

    > Jetzt wird Apple schon kritisiert dafür, dass sie es wagen offene Standards
    > zu schaffen, nur weil sie nicht auf dem Standard setzten, den du persönlich
    > toll findest.
    Bisher haben sie ueberhaupt gar nichts Brauchbares geschaffen, also Fuesse stillhalten.

    > Wer bitte sagt, dass Vulkan so toll ist oder das es die beste
    > 3D API überhaupt ist? Kennst du dich überhaupt mit 3D APIs aus? Weißt du
    > überhaupt wie sich Vulkan, Direct3D und Metal unterscheiden? Hast du schon
    > mal mit allen drei gearbeitet? Und wenn nicht, woher willst du dann wissen
    > das Vulkan so toll ist?

    Du ja offenbar nicht, trotzdem haeltst du es fuer angebracht dazwischenzufunken. Wieso?

    > Weil es das für mehr als eine Plattform gibt? Das alleine macht es noch
    > lange nicht toll. Die APIs selber, Direct3D und Metal, wären genauso
    > portabel auf alle Plattformen, gemeint ist hier nicht der Code, sondern die
    > Schnittstelle. Denn viel mehr als die Schnittstelle wird bei Vulkan auch
    > nicht portiert, denn der Rest ist natürlich in weitein Teilen
    > plattformabhängig und damit nicht portierbar

    d3d kann alleine schon aus lizenzrechtlichen Gruenden nicht mal eben portiert werden, weil es proprietaer ist. Metal genauso.
    Und selbstverstaendlich ist Vulkan Code portabel. So laeuft Doom etwa auf Linux, obwohl es nur einen offiziellen Windows Client gibt.
    Treiber sind immer noch abstrahiert und die Userspace-Treiber fuer Vulkan werden mindestens bei Nvidia und AMD zwischen den Plattformen (Windows + Linux) geteilt.

    > denn anders als OpenGL macht
    > Vulkan ja selber fast nichts mehr; Vulkan soll ja nur noch einen ganz dünne
    > Layer zwischen der App und dem Grafikkartentreiber (und damit der GPU
    > selber) sein. Ergo ist da auch nicht viel Code. Der Code beschränkt sich
    > darauf von der App Anweisungen entgegen zu nehmen und die in etwas zu
    > übersetzen, dass der Grafikkartentreiber versteht (der dass dann wiederum
    > in etwas übersetzt, dass die GPU selber versteht) und natürlich sind
    > Grafikkartentreiber auf jeder Plattform anders und auch ganz anders in das
    > System eingebunden, ergo gibt es da nichts, was man groß portieren könnte.

    Humbug, s.o.

  7. Re: Das ist wohl ein schlechter Scherz!

    Autor: körner 08.02.17 - 20:57

    gaciju schrieb:
    --------------------------------------------------------------------------------
    > Panzergerd schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > WebM, ein Videoformat das auf vielen Imageboards verwendet wird, können
    > sie
    > > auch immer noch nicht.
    >
    > MS uebrigens auch nicht.

    Stimmt doch nicht: https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-microsoft-edge/#AxxrOYHBdAQMv0DX.97

    Apple ist ne Drecksfirma.

  8. Re: Das ist wohl ein schlechter Scherz!

    Autor: gaciju 08.02.17 - 21:08

    körner schrieb:
    --------------------------------------------------------------------------------
    > gaciju schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Panzergerd schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > WebM, ein Videoformat das auf vielen Imageboards verwendet wird,
    > können
    > > sie
    > > > auch immer noch nicht.
    > >
    > >
    > > MS uebrigens auch nicht.
    >
    > Stimmt doch nicht: blogs.windows.com#AxxrOYHBdAQMv0DX.97

    Danke fuer die Info.
    Ich habe nachgeschaut und es ist ein experimentelles Feature. Man kann ein Flag setzen, um VP9 decoding zu aktivieren. Automatisch geschieht das nur, wenn auch Hardware Decoder an Bord sind. VP8 gibt es dagegen immer noch gar nicht.

    Edit: Von wegen. Software decoding geht nicht. Mit Firefox und Chrome(/ium) keine Probleme auf Linux und Windows.
    Also nur mit den neuesten GPUs und nur VP9. Da von webm-Kompatibilitaet zu sprechen ist schon etwas weit hergeholt.

    > Apple ist ne Drecksfirma.

    Nanana



    1 mal bearbeitet, zuletzt am 08.02.17 21:11 durch gaciju.

  9. Re: Das ist wohl ein schlechter Scherz!

    Autor: /mecki78 08.02.17 - 21:24

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > Der Unterschied ist: MS hat auch nie OpenGL 1.2 oder höher angeboten

    Hier wird mal wieder Geschichtsfälschung versucht; das muss ich leider sehr oft feststellen in verschiedenen Foren in letzter Zeit. Entweder glauben die Poster, dass es eh niemand besser weiß oder dass sich niemand die Mühe macht die Fakten nachzuprüfen, oder aber, und das wäre aber irgendwie dämlich, die Poster wissen es selber nicht besser, aber dann müssten sie zumindest wissen, dass sie es nicht wissen (man weiß doch was man weiß und was nicht) und nicht noch damit hausieren gehen.

    Microsoft hat OpenGL nicht nur angeboten, sie haben es sogar speziell für Windows erweitert (WGL) und sie haben den Standard sogar mitgestaltet, da sie damals selber Mitglieder mit festen Sitz im ARB ("Architecture Review Board") waren.

    Zitat:
    "Prior 1994, OpenGL was the most prominent graphics API back then.Well, in the development of Windows NT (New Technology), Microsoft even included the OpenGL as the 3D rendering API. However, as the giant who never satisfied with the dine, Microsoft began it’s campaign to win over game developers. They began their newly created API called Direct3D."
    https://personanonymous.wordpress.com/2012/07/12/a-brief-history-of-opengl-vs-microsoft-directx/

    Auch in Windows 95 gab es eine opengl.dll und die kam von Microsoft ("(c) Microsoft ...") und zwar bevor es Direct3D gab, das zum ersten mal 1996 vorgestellt wurde. Dass das damals 1.1 und nicht 1.2 war lag nur daran, dass 1.2 erst 1998 fertig geworden ist und da hatte Microsoft schon lange entschieden, dass Direct3D die Zukunft gehört.

    Und seit Windows Vista ist ab Werk ja sogar OpenGL 1.4 im System installiert und das kommt von Microsoft selber (1.4 > 1.2). Das setzt zwar intern auf Direct3D auf (wenn man so will ist es eine auf Direct3D aufgesetzte OpenGL Emulation), aber wie du OpenGL implementierst war ja schon immer dir selber überlassen. Der Standard gibt nur vor wie die API aussieht, die Implementierung gibt er nicht vor.

    > Apple hingegen bot bis vor kurzem offiziell
    > nur OpenGL als offizielle 3D-API

    Und daraus macht du ihnen einen Vorwurf? Apple hat mit Metal nur genau das gemacht, was Microsoft bereits 1996 getan hat, nämlich eine API, über die sie keine volle Kontrolle hatten und die nicht so funktioniert wie sie mochten bzw. nicht die Leistung erbringen konnte, wohl aber eine enorm gewichtige Rolle im System spielt (Apple nutzt die ja z.B. auch massiv für normale App UI), durch eine neue, eigenen API zu ersetzen, über die sie die Kontrolle haben und die die Leistung bringt. Bedenkt man das es ihr System ist (macOS/iOS) und sie ja auch sonst so ziemlich alle anderen APIs dort kontrollieren, klingt das eigentlich nur natürlich.

    Warum sie nicht Vulkan genommen haben? Weil sie Metal schon Mitte 2014 vorgestellt haben als fertige API (entsprechend lange wurde also schon daran gearbeitet und entsprechend viel früher musste es schon dieses Konzept geben), Vulkan aber gerade mal Mitte 2015 auf der GDC als Konzept vorgestellt wurde, da war noch nichts an der API final und eine fertige Implementierung gab es auch noch nicht. Erst Anfang 2016 war überhaupt mal die Spezifikation final und erst dann kann man an richtigen Implementierungen arbeiten. Als also Apple mit Metal angefangen hat, da gab es noch nicht einmal die Idee von Vulkan, die wurde erst 2014 geboren und da war Apple mit Metal schon fertig! Ich hoffe also du fragst bitte nicht ernsthaft warum Apple nicht auf etwas gewartet hat, von dem nicht einmal absehbar war, dass es das jemals geben wird.

    > an und lieferte die (veraltete) Implementierung AFAIK selber...

    Die Implementierung war nicht veraltet. Apple hat mit jedem macOS Release eine OpenGL Version ausgeliefert, die zum Zeitpunkt als die Arbeiten an dem Release begangen (was ja lange vor dem Release ist) noch aktuell war ("noch" heißt nicht die aller neuste, aber auch nicht hoffnungslos veraltet), garantiert stabil war (schon länger im Betrieb, ausführlich getestet) und den Fähigkeiten der in Macs verbauten Grafikchips entsprach (was ja auch nicht immer die aller neusten Chips auf dem Markt waren).

    Ich meine, dass Apple nicht auf gerade frisch standardisierte APIs setzt, das finde ich mehr als sinnvoll. Und dass sie nicht 3 Tage vor dem finalen Release dann schnell OpenGL 3.1 gegen OpenGL 3.2 tauschen, nachdem sie jetzt ein Jahr lang nur mit 3.1 gearbeitet und getestet haben, das macht auch irgendwie Sinn. Ansonsten vergessen die meisten Leute, dass in Macs nicht unbedingt Bleeding Edge Grafikchips verbaut werden, so wie sie Gamer in ihren PC stecken. Warum sollte das OpenGL von macOS also Dinge unterstützen, die keine von Apple verbaute GPU in Hardware kann? Wo genau wäre da der Sinn? Ja, doof wenn PC Games diese Funktion brauchen, aber die GPU hätte sie so oder so nicht gekonnt, auch nicht mit neuer OpenGL Version.

    Außerdem sagt die Versionsnummer bei OpenGL gar nichts aus, denn es gibt ja Erweiterungen. Ich kann ein OpenGL 1.2 anbieten, dass über Erweiterungen den kompletten Funktionsumfang von OpenGL 4.0 anbietet. So hat Apple mal ein System mit OpenGL 3/3.1 ausgeliefert, je nach Grafikkarte. Und alle waren am weinen "Warum nicht 3.3?" Aber faktisch standen alle neuen Funktionen von 3.3 als Erweiterungen zur Verfügung für alle Grafikkarten, die diese auch beherrschten. Es wäre also problemlos möglich gewesen OpenGL 3.3 Spiele zu portieren und die Aussage "Geht nicht, weil macOS ja nur 3.1 kann" ist nichts weiter als eine Ausrede, weil man zu faul war hier ein bisschen Code so umzuschreiben, dass er halt die Erweiterung nutzt bzw. ihn gleich so zu schreiben, dass er beides kann (3.3 Release oder die Erweiterung nutzten), denn fast jedes Feature, dass er irgendwann in den Core von OpenGL geschafft hat, existierte davor schon ewig lange als Erweiterung.

    Selbst Shader gab es schon als Erweiterung als Apple noch OpenGL 1.4 angeboten hatte. Ich weiß das, weil ich hier schon Code geschrieben habe, der eben genau das macht: Er schaut was die OpenGL Version ist. Ist die neuer als X, dann nutzt er die Core Funktion. Wenn nicht, dann schaut er ob die Erweiterung angeboten wird und falls ja, dann nutzt er die. Und falls auch nicht, dann geht diese Funktion nicht und die App muss eben auf etwas anderes zurück greifen oder kann auf dieser Hardware gar nicht genutzt werden, ist dann halt so.

    Erweiterungen war einer der großen Pluspunkte von OpenGL, weil hier jeder Hersteller selber welche spezifizieren durfte. Wollte NVidia oder ATI (heute AMD) etwas bieten, dass es in OpenGL nicht gab, dann haben sie einfach eine herstellerspezifische Erweiterung gemacht(GL_ATI_*, GL_NVIDIA_*). Hatten dann zwei oder mehr Hersteller dann eine gleiche oder ähnliche Erweiterung, dann hat man sich zusammengesetzt und eine herstellerübergreifende Erweiterung spezifiziert (GL_EXT_*), die dann quasi die bisherige ersetzt hat (die bisherige war ab dort dann "veraltet" und wurde nicht weiter entwickelt). Und wenn diese Erweiterung irgendwann von der Mehrzahl der Hersteller und deren Karten unterstützt wurde, dann wurde aus dieser Erweiterung einen offizielle vom ARB abgesegnete Erweiterung (GL_ARB_*). Und irgendwann, wenn eine neue OpenGL Version kam, dann wurde entschieden welche Erweiterungen Teil der Core Spezifikation werden (GL_*).

    Die GPU Hersteller mussten nicht warten, bis der Standard angepasst wurde, die konnten sofort loslegen. Das ist bei DX und Metal ein Nachteil, weil die können sie nicht selber einfach so erweitern, das geht nur über Microsoft/Apple.

    /Mecki

  10. Re: Das ist wohl ein schlechter Scherz!

    Autor: MadMonkey 08.02.17 - 21:48

    /mecki78 schrieb
    > Erweiterungen war einer der großen Pluspunkte von OpenGL, weil hier jeder
    > Hersteller selber welche spezifizieren durfte. Wollte NVidia oder ATI
    > (heute AMD) etwas bieten, dass es in OpenGL nicht gab, dann haben sie
    > einfach eine herstellerspezifische Erweiterung gemacht(GL_ATI_*,
    > GL_NVIDIA_*). Hatten dann zwei oder mehr Hersteller dann eine gleiche oder
    > ähnliche Erweiterung, dann hat man sich zusammengesetzt und eine
    > herstellerübergreifende Erweiterung spezifiziert (GL_EXT_*), die dann quasi
    > die bisherige ersetzt hat (die bisherige war ab dort dann "veraltet" und
    > wurde nicht weiter entwickelt). Und wenn diese Erweiterung irgendwann von
    > der Mehrzahl der Hersteller und deren Karten unterstützt wurde, dann wurde
    > aus dieser Erweiterung einen offizielle vom ARB abgesegnete Erweiterung
    > (GL_ARB_*). Und irgendwann, wenn eine neue OpenGL Version kam, dann wurde
    > entschieden welche Erweiterungen Teil der Core Spezifikation werden (GL_*).

    Wie bitte?!? Das ist und bleibt der Hauptgrund warum sich OpenGL nie durchsetzten konnte! Wie will man eine vernünftige Engine entwickeln die performant ist und auf mehr als einer Graka läuft wenn man für jedes kleinste Feature X-Verschiedene Extensions prüfen muss?!? Wohlgemerkt muss man das ja nicht nur prüfen sondern auch immer anders implementieren. Und dass die Hersteller brav zusammensitzen und Extensions vereinheitlichen passierte ja wohl nie oder wenn, dann mit 5 Jahren Verspätung. Das ist Nr 1. Grund warum OpenGL auf Pc's versagt hat. Und wenn du jetzt mit Smartphones und Konsolen kommen willst: Bei der Konsole hast du das Problem nicht weil da ja immer die gleiche Karte drin steckt, genauso bei iPhones. Und auch bei Android gibt es eigentlich auch nicht wirklich viele unterschiedliche SoCs. Schau dir nur mal an welche Extensions gemeinsam von Intel, Amd und Nvidia implementiert werden: nur solche die schon Jahre alt sind!

  11. Re: Das ist wohl ein schlechter Scherz!

    Autor: pythoneer 08.02.17 - 21:49

    Mensch mecki78, da hast du dir aber ein ordentliches Ei ins Nest gelegt. Ich werde das jetzt mal Stück für Stück auseinander nehmen, versuche aber nett zu bleiben – wir mögen uns ja in den meisten Fällen gut leiden ;)

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Nein, das liegt exakt daran, dass niemand Vulkan für MacOS implementiert.

    Richtig, weil Apple es eben nicht vorsieht – im Gegensatz zu Windows und Linux etc. – das andere Treiber für zum Beispiel Grafikkarten zur Verfügung stellen, die nicht von Apple kommen! So wirst du – in der Regel – keine Grafikkartentreiber von den IHV's sehen, denn die kommen so gut wie immer von Apple selber. Ob Apple die völlig selber schreibt darf bezweifelt werden und wird wohl in "Partnerschaft" mit den IHV's entwickelt (wohl möglich macht Apple nur vorgaben was der IHV abzuliefern hat, das hat er zu machen oder landet halt nicht in einem Apple Computer). Auf jeden Fall landet nur das im Treiber was Apple vorgibt was dort drin landet. Von Nvidia gibt es meines Wissens extra installierbare Treiber zum Beispiel für ihre Quadro Karten die es aber auch nur im Aftersale gibt und nicht standardmäßig in Apple Computern ausgeliefert werden. Diese Treiber*¹ sind meines Wissens auch mit den "normalen" Karten einigermaßen kompatibel und damit die einzige Möglichkeit unter macOS eine halbwegs Aktuelle OpenGL Version zum laufen zu bekommen. Von AMD oder Intel ist mir das hingegen nicht bekannt. Was da für schattige Verträge im Hintergrund laufen und ob die Quadro Treiber überhaupt von Apple supported werden weiß ich nicht. Auf jeden Fall ist das in keinster Weise mit der Lage auf Windows oder Linux zu vergleichen wo es so einen Affentanz nicht gibt.

    > Warum Apple das nicht macht? Warum macht es denn Microsoft nicht für
    > Windows? Es gibt Vulkan für Windows, aber das kommt schließlich auch nicht
    > von Microsoft. Also warum wird von Apple immer das gefordert, was Microsoft
    > z.B. noch nie gemacht hat?

    Ich glaube ich habe dir das recht gut oben erläutert. Treiber auf macOS kommen nur von Apple (gewollt) auf Windows und Linux kann die jeder selber machen (IHV und auch 'Hobbyprogrammierer' wie man an den freien Treibern unter Linux sieht)

    Man kann nicht direkt sagen, dass Apple das öffentlich verbietet aber sie werden sich schon Vertraglich abgesichert haben, dass Nvidia, Intel und AMD nicht dazwischen funken und auf einmal Vulkan Treiber zur Verfügung stellen. Wie gesagt es gibt – halb inoffizielle – Treiber von z.b. Nvidia mit viel neueren OpenGL Implementationen. Interessieren tut es Apple nicht und veröffentlicht keine offiziellen neueren Versionen. Warum auch? Metal Fist!

    > Und was ist schlecht daran, wenn ein Webstandarad eben nicht auf X oder auf
    > Y basiert, sondern so neutral ist, dass es letztlich auf allen möglichen
    > basieren kann, sogar auf OpenGL (auch wenn er dann natürlich nicht die
    > großartige Performance haben wird). Ich würde deine Kritik verstehen, wenn
    > das quasi Metal wäre und auch nur mit Metal funktionieren würde, aber dem
    > ist ja nicht so.

    Weil der Vorschlag eben mit Metal ist! Es ist ja nichts konkretes festgelegt darum kann man auch noch nichts konkretes kritisieren aber ich darf einfach mal zitieren:

    "For our WebGPU prototype, we decided to defer the issue and just accept an existing language for now. Since we were building on Apple platforms we picked the Metal Shading Language."

    Na Mensch – so ein Zufall aber auch! Die Metal Shading Language "liegt" gerade so rum, na dann nehmen wir die doch einfach mal – kein großes Ding. Wir hätten auch Würfeln können aber Metal biete sich gerade einfach an.

    Ja es gibt noch nichts konkretes, wer diese Aussage aber nicht "shady" findet ...

    > Vulkan und sogar Direct3D waren von Anfang an als mögliche
    > Unterbauten vorgesehen. Damit ist das besser als WebGL jemals war, weil das
    > sah genau nur OpenGL als Unterbau vor (und das auf z.B. Direct3D abzubilden
    > ist in etwa so, als ob man gleich ganz OpenGL über Direct3D abbildet und
    > dürfte sehr schlechte Performance liefern).

    Ja, kein Ding. Die anderen dürfen sich gerne die Mühe machen das irgendwie in D3D oder Vulkan hinein zu prügeln. Anders als bei WebGL was GLES als Unterbau hat und genau dafür gibt es ANGLE was man übrigens auch für Qt Anwendungen benutzen kann. Das kommt von Goole und läuft wunderbar.

    > Jetzt wird Apple schon kritisiert dafür, dass sie es wagen offene Standards
    > zu schaffen, nur weil sie nicht auf dem Standard setzten, den du persönlich
    > toll findest.

    Wo habe ich Apple dafür kritisiert? Bitte zitiere mich! Ich habe Apple dafür kritisiert so einen Unsinn zu schreibe, dass sie es "sehr schade" finden, dass es noch keine API gibt die auf allen Plattformen läuft – was einzig und allein ihre Schuld ist. Was man "nebenher" noch als meine Kritik ansehen kann ist der scheinbare Versuch Metal als offenen Web Standard zu verkaufen. In dem sie "einfach erst einmal unverbindlich" – mal schnell – die Metal Shading Language für ihren Prototypen verwenden. Völlig ohne Hintergedanken.

    > Wer bitte sagt, dass Vulkan so toll ist oder das es die beste
    > 3D API überhaupt ist?

    Ja, sag du es mir wer das sagt! Ich habe das bestimmt nicht gesagt. Solltest du da anderer Meinung sein, dann darfst du mich gerne zitieren und das Gegenteil beweisen. Ansonsten sehe ich das einfach mal als heiße Luft von dir an.

    > Kennst du dich überhaupt mit 3D APIs aus?

    Ja, einigermaßen. Ich schreibe hin und wieder mit OpenGL kleinere Engines. Hier ein etwas älterer Versuch in der Programmiersprache D-lang (um die Sprache zu lernen)
    https://github.com/pythoneer/3DGameEngineD

    Hier ein kleiner Software Renderer der Unter dem Betriebsystem Redox https://redox-os.org/ läuft

    https://github.com/pythoneer/pixelcannon/


    mehr habe ich gerade nicht online verfügbar, das meiste darf ich auch nicht online stellen weil es in meiner Tätigkeit als Programmierer entstanden ist und ich nicht die Rechte besitze diese zu veröffentlichen. Bis D3D8 und kurz nach 9 hab ich auch mit D3D gearbeitet bin dann aber Vollständig zu Linux gewechselt. Metal kenn ich allerdings wirklich nur rudimentär – beruflich – und im Falle von Vulkan experimentiere ich gerade mit https://github.com/tomaka/vulkano in der Programmiersprache Rust.

    Ich weiß nicht in wie weit das für dich als Qualifikation reicht, das interessiert mich aber auch nicht sonderlich.

    > Weißt du überhaupt wie sich Vulkan, Direct3D und Metal unterscheiden?

    Ja.

    > Hast du schon mal mit allen drei gearbeitet?

    Ja.

    > Und wenn nicht, woher willst du dann wissen das Vulkan so toll ist?

    Ich habe nirgends behauptet, dass Vulkan so toll ist. Falls du das anders siehst, ich bitte darum, dass du besagte stelle von mir zitierst.

    > Weil es das für mehr als eine Plattform gibt? Das alleine macht es noch
    > lange nicht toll.

    Ich habe nirgends behauptet. Falls du das anders siehst, ich bitte darum, dass du besagte stelle von mir zitierst.

    > Die APIs selber, Direct3D und Metal, wären genauso
    > portabel auf alle Plattformen, gemeint ist hier nicht der Code, sondern die
    > Schnittstelle.

    Soweit ich weiß (zimindest zu D3D9 Zeiten) war die API einigermaßen "Windowslastig". Bei Metal bin ich mir nicht so ganz sicher aber da könntest du recht haben. In Vulkan ist das in der Hinsicht aber wirklich nicht schlecht gelöst. Ich behaupte auch gar nicht, dass sich Vulkan besser für eine Webversion eignen würde – das war auch überhaupt nicht meine Kritik!

    > Denn viel mehr als die Schnittstelle wird bei Vulkan auch
    > nicht portiert, denn der Rest ist natürlich in weitein Teilen
    > plattformabhängig und damit nicht portierbar, denn anders als OpenGL macht
    > Vulkan ja selber fast nichts mehr; Vulkan soll ja nur noch einen ganz dünne
    > Layer zwischen der App und dem Grafikkartentreiber (und damit der GPU
    > selber) sein. Ergo ist da auch nicht viel Code. Der Code beschränkt sich
    > darauf von der App Anweisungen entgegen zu nehmen und die in etwas zu
    > übersetzen, dass der Grafikkartentreiber versteht (der dass dann wiederum
    > in etwas übersetzt, dass die GPU selber versteht) und natürlich sind
    > Grafikkartentreiber auf jeder Plattform anders und auch ganz anders in das
    > System eingebunden, ergo gibt es da nichts, was man groß portieren könnte.

    Ich lass das einfach mal unkommentiert stehen.

    *¹ http://www.nvidia.com/download/driverResults.aspx/96651/en-us

    Linux is highly user friendly, it is just highly selective who it is friends with.



    1 mal bearbeitet, zuletzt am 08.02.17 21:59 durch pythoneer.

  12. Re: Das ist wohl ein schlechter Scherz!

    Autor: QDOS 08.02.17 - 22:31

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Microsoft hat OpenGL nicht nur angeboten, sie haben es sogar speziell für
    > Windows erweitert (WGL)
    Also den ganzen Wall of Text kommentiere ich einfach nicht - da hat jemand offensichtlich viel zu viel Zeit...

    Und nur zur Info, da du anscheinend öfter Probleme hast Technologien richtig zu identifizieren (DirectX sei C#...) : WGL ist eine API damit man in Windows einen OpenGL Kontext erzeugen und verwalten kann... Das ist keine Erweiterung von OpenGL, genau so wenig wie Apples CGL, oder GLX Erweiterungen von OpenGL sind!

  13. Re: Das ist wohl ein schlechter Scherz!

    Autor: j_h_schmidt 09.02.17 - 10:20

    Na klar - ist ja auch ein Google Format. Aber wir sind ja bei GOlem - da sind Sachen die Google macht immer voll c00l und was z.B. Apple macht immer ultraböse! ;)

  14. Re: Das ist wohl ein schlechter Scherz!

    Autor: j_h_schmidt 09.02.17 - 10:27

    gaciju schrieb:
    > Hauptsache sie haben keine Arbeit, alle anderen duerfen aber zusaetzlich
    > eine voellig neue Schnittstelle mit 2-3 neuen Backends implementieren.

    Also exakt so wie das Google seit jahren mit Webstandards handhabt? IndexDB? ServiceWorkers? CustomElements? ShadowDOM? Progressive Web Apps? WebM? Auch da hat Google mit initialen Implementierungen in Chrome und massiver Marketingtrommelei Tatsachen geschaffen die dann von anderen Browserherstellern gefälligst so zu implementieren sind. Aber klar: Wenn Google das macht ist es natürlich ok #hybris

    >
    > > Vulkan und sogar Direct3D waren von Anfang an als mögliche
    > > Unterbauten vorgesehen. Damit ist das besser als WebGL jemals war, weil
    > das
    > > sah genau nur OpenGL als Unterbau vor
    >
    > Auch das ist falsch. WebGL basiert auf GLES.
    >
    > > ist in etwa so, als ob man gleich ganz OpenGL über Direct3D abbildet und
    > > dürfte sehr schlechte Performance liefern).
    >
    > Du wirst lachen, aber Mozilla und Google verwenden fuer ihre Browser ANGLE,
    > was WebGL/GLES auf d3d mappt, weil es idR. besser performt.
    >
    > > Jetzt wird Apple schon kritisiert dafür, dass sie es wagen offene
    > Standards
    > > zu schaffen, nur weil sie nicht auf dem Standard setzten, den du
    > persönlich
    > > toll findest.
    > Bisher haben sie ueberhaupt gar nichts Brauchbares geschaffen, also Fuesse
    > stillhalten.
    >
    > > Wer bitte sagt, dass Vulkan so toll ist oder das es die beste
    > > 3D API überhaupt ist? Kennst du dich überhaupt mit 3D APIs aus? Weißt du
    > > überhaupt wie sich Vulkan, Direct3D und Metal unterscheiden? Hast du
    > schon
    > > mal mit allen drei gearbeitet? Und wenn nicht, woher willst du dann
    > wissen
    > > das Vulkan so toll ist?
    >
    > Du ja offenbar nicht, trotzdem haeltst du es fuer angebracht
    > dazwischenzufunken. Wieso?
    >
    > > Weil es das für mehr als eine Plattform gibt? Das alleine macht es noch
    > > lange nicht toll. Die APIs selber, Direct3D und Metal, wären genauso
    > > portabel auf alle Plattformen, gemeint ist hier nicht der Code, sondern
    > die
    > > Schnittstelle. Denn viel mehr als die Schnittstelle wird bei Vulkan auch
    > > nicht portiert, denn der Rest ist natürlich in weitein Teilen
    > > plattformabhängig und damit nicht portierbar
    >
    > d3d kann alleine schon aus lizenzrechtlichen Gruenden nicht mal eben
    > portiert werden, weil es proprietaer ist. Metal genauso.
    > Und selbstverstaendlich ist Vulkan Code portabel. So laeuft Doom etwa auf
    > Linux, obwohl es nur einen offiziellen Windows Client gibt.
    > Treiber sind immer noch abstrahiert und die Userspace-Treiber fuer Vulkan
    > werden mindestens bei Nvidia und AMD zwischen den Plattformen (Windows +
    > Linux) geteilt.
    >
    > > denn anders als OpenGL macht
    > > Vulkan ja selber fast nichts mehr; Vulkan soll ja nur noch einen ganz
    > dünne
    > > Layer zwischen der App und dem Grafikkartentreiber (und damit der GPU
    > > selber) sein. Ergo ist da auch nicht viel Code. Der Code beschränkt sich
    > > darauf von der App Anweisungen entgegen zu nehmen und die in etwas zu
    > > übersetzen, dass der Grafikkartentreiber versteht (der dass dann
    > wiederum
    > > in etwas übersetzt, dass die GPU selber versteht) und natürlich sind
    > > Grafikkartentreiber auf jeder Plattform anders und auch ganz anders in
    > das
    > > System eingebunden, ergo gibt es da nichts, was man groß portieren
    > könnte.
    >
    > Humbug, s.o.

  15. Re: Das ist wohl ein schlechter Scherz!

    Autor: j_h_schmidt 09.02.17 - 11:07

    pythoneer schrieb:
    > Auf jeden Fall landet nur das im Treiber was Apple vorgibt was
    > dort drin landet.

    Das ist noch nicht einmal "Hörensagen" - das ist einfach nur eine Meinung... in Zeiten in der Meinungen offensichtlich wichtiger sind als Fakten.

    > Von Nvidia gibt es meines Wissens extra installierbare
    > Treiber zum Beispiel für ihre Quadro Karten die es aber auch nur im
    > Aftersale gibt und nicht standardmäßig in Apple Computern ausgeliefert
    > werden.

    Die Hardware in Apple Computern ist weitgehend fix - es macht absolut Sinn das Apple die dazu notwendigen Treiber mitliefert. Die Installation von Third-Party-Treibern wird nicht explizit unterbunden ist aber schlicht und einfach unüblich.

    > ...ist mir das hingegen nicht bekannt. Was da für schattige Verträge im
    > Hintergrund laufen und ob die Quadro Treiber überhaupt von Apple supported
    > werden weiß ich nicht. Auf jeden Fall...

    Hm... merkst Du was? ;-)

    > Ich glaube ich habe dir das recht gut oben erläutert. Treiber auf macOS
    > kommen nur von Apple (gewollt) auf Windows und Linux kann die jeder selber
    > machen (IHV und auch 'Hobbyprogrammierer' wie man an den freien Treibern
    > unter Linux sieht)

    Stimmt aber schlicht nicht - auch unter MacOS X kann jeder Treiber machen. Das wird von Apple nicht unterbunden. Da Apple aber kein "Betriebssystemanbieter für Fremdhardware" ist sondern ein "Komplettsystemanbieter" macht ein Engagement von Drittanbieter-Treibern für die selbst kombinierte Hardware wenig Sinn. Stattdessen würde es die Supportfälle drastisch erhöhen, denn es installieren ja nicht nur vermeintliche "Profis" Fremdtreiber sondern schlicht und einfach jeder Depp der sich davon ein bisschen Beschleunigung verspricht. Aber wie bereits gesagt: Es ist nicht verboten Fremdtreiber anzubieten und es ist nicht verboten sie zu installieren.

    > ... aber sie
    > werden sich schon Vertraglich abgesichert haben, dass Nvidia, Intel und AMD
    > nicht dazwischen funken und auf einmal Vulkan Treiber zur Verfügung
    > stellen.

    Mutmaßung

    > Weil der Vorschlag eben mit Metal ist! Es ist ja nichts konkretes
    > festgelegt darum kann man auch noch nichts konkretes kritisieren aber ich
    > darf einfach mal zitieren:
    >
    > "For our WebGPU prototype, we decided to defer the issue and just accept an
    > existing language for now. Since we were building on Apple platforms we
    > picked the Metal Shading Language."
    >
    > Na Mensch – so ein Zufall aber auch! Die Metal Shading Language
    > "liegt" gerade so rum, na dann nehmen wir die doch einfach mal – kein
    > großes Ding. Wir hätten auch Würfeln können aber Metal biete sich gerade
    > einfach an.

    Sie arbeiten nach eigener Aussage seit ein paar Jahren daran und haben insbesondere durch den Prototypen evaluiert ob es einen messbaren Vorteil bietet. Sie legten bislang fest, dass sie die Entscheidung für eine Shadersprache bislang "vertagt" haben - weil sie (steht auch im Text) erwarten das sich große Teile der Diskussionen darum drehen werden. Für den Prototyp musste aber etwas benutzt werden - warum also nicht auf den eigenen Systemen erstmal die eigene Shadersprache benutzen? Ist das so seltsam? Apple macht es hier eigentlich genau richtig - Evaluation des Konzeptes möglichst einfach, aber im Rahmen der Diskussion in der Arbeitsgruppe bereits vorab deutlich machen das dieser Teil mit an Sicherheit grenzender Wahrscheinlichkeit nicht so kommen wird. Eigentlich vorbildlich.

    > Ja es gibt noch nichts konkretes, wer diese Aussage aber nicht "shady"
    > findet ...

    Du findest es einfach "shady" weil es von Apple kommt - nicht ob des Inhalts. Ist halt nicht Google. ;)

    > Wo habe ich Apple dafür kritisiert? Bitte zitiere mich! Ich habe Apple
    > dafür kritisiert so einen Unsinn zu schreibe, dass sie es "sehr schade"
    > finden, dass es noch keine API gibt die auf allen Plattformen läuft –
    > was einzig und allein ihre Schuld ist. Was man "nebenher" noch als meine
    > Kritik ansehen kann ist der scheinbare Versuch Metal als offenen Web
    > Standard zu verkaufen. In dem sie "einfach erst einmal unverbindlich"
    > – mal schnell – die Metal Shading Language für ihren Prototypen
    > verwenden. Völlig ohne Hintergedanken.

    Oder anders ausgedrückt: Du kritisierst Apple dafür (deiner Meinung nach) plattformübergreifende Standards bewusst zu blockieren. Und Du unterstellst ihnen, dass alleine durch die Verwendung ihrer eigenen Shading Language in einem _ihrer_ Prototypen trotz _explizitem_ Hinweis, das sich um die Shadersprache wohl die meisten Diskussionen drehen werden hintenrum anderen Metal aufdrücken wollen.

    Beides Kritik, mindestens eines davon völlig zu unrecht.

  16. Re: Das ist wohl ein schlechter Scherz!

    Autor: /mecki78 09.02.17 - 14:29

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > Also den ganzen Wall of Text kommentiere ich einfach nicht -

    Genau! Fakten, die dir nicht gefallen und deine Behauptungen widerlegen, die muss man auch nicht kommentieren. Denn diese Fakten existieren einfach nicht. Von Trump lernen heißt siegen lernen.

    > da hat jemand offensichtlich viel zu viel Zeit...

    Die ich nicht aufbringen müsste, wenn hier nicht jemand wäre, der offensichtlich viel zu wenig Ahnung von dem Thema hat, aber dennoch meint mit den Großen mitreden zu müssen.

    > WGL ist eine API damit man
    > in Windows einen OpenGL Kontext erzeugen und verwalten kann... Das ist
    > keine Erweiterung von OpenGL,

    Doch, ist es.
    Es erweitert OpenGL um die Funktion einen Kontext zu erzeugen.
    Wäre Microsoft OpenGL egal wie du behauptet hast, hätten sie OpenGL nie unterstützen wollen wie du geschrieben hast, warum genau hätte Microsoft dann so was implementieren sollen? Wie man sonst hätte in Windows einen OpenGL Kontext bekommen können? Keine Ahnung, aber wieso wäre dass Microsofts Problem gewesen, wenn ihnen OpenGL angeblich so was von egal war? Dann hätte sich eben SGI was einfallen lassen müssen.

    > genau so wenig wie Apples CGL, oder GLX
    > Erweiterungen von OpenGL sind!

    Doch, sind sie.
    Ich habe keine Ahnung wie du persönlich für dich den Begriff "Erweiterung" definierst, aber wenn man zu einer fertigen API weiter Funktionen hinzufügst, z.B. solche die man braucht um diese API auf einen bestimmten System nutzen zu können, dann würden 99,99% aller Programmierer da draußen das "eine Erweiterung" nennen.

    /Mecki

  17. Re: Das ist wohl ein schlechter Scherz!

    Autor: gaciju 09.02.17 - 18:18

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Genau! Fakten, die dir nicht gefallen und deine Behauptungen widerlegen,
    > die muss man auch nicht kommentieren.

    Das machst du doch genauso, s. mein Beitrag weiter oben.

    > Denn diese Fakten existieren einfach
    > nicht. Von Trump lernen heißt siegen lernen.

    Du solltest aufhoeren, deinem Vorbild hier so nachzueifern, machst dich naemlich ziemlich laecherlich damit.

    > wenn hier nicht jemand wäre, der
    > offensichtlich viel zu wenig Ahnung von dem Thema hat, aber dennoch meint
    > mit den Großen mitreden zu müssen.

    Danke fuer die Empathie

    > > WGL ist eine API damit man
    > > in Windows einen OpenGL Kontext erzeugen und verwalten kann... Das ist
    > > keine Erweiterung von OpenGL,
    >
    > Doch, ist es.
    > Es erweitert OpenGL

    Nein

    > > genau so wenig wie Apples CGL, oder GLX
    > > Erweiterungen von OpenGL sind!
    >
    > Doch, sind sie.

    NEIN!
    Das sind Erweiterungen der windowing Systeme und nicht von OpenGL

    > Ich habe keine Ahnung wie du persönlich für dich den Begriff "Erweiterung"
    > definierst, aber wenn man zu einer fertigen API weiter Funktionen
    > hinzufügst, z.B. solche die man braucht um diese API auf einen bestimmten
    > System nutzen zu können

    Zum letzten Mal: man erweitert "das System", um die API nutzen zu koennen und nicht andersherum.

  18. Re: Das ist wohl ein schlechter Scherz!

    Autor: gaciju 09.02.17 - 18:22

    j_h_schmidt schrieb:
    --------------------------------------------------------------------------------
    > Also exakt so wie das Google seit jahren mit Webstandards handhabt?
    > IndexDB? ServiceWorkers? CustomElements? ShadowDOM? Progressive Web Apps?
    > WebM? Auch da hat Google mit initialen Implementierungen in Chrome und
    > massiver Marketingtrommelei Tatsachen geschaffen die dann von anderen
    > Browserherstellern gefälligst so zu implementieren sind. Aber klar: Wenn
    > Google das macht ist es natürlich ok #hybris

    Entschuldige, ich habe nicht mitbekommen, dass der Artikel ueber Google geht.

    Es tut mir auch furchtbar Leid, wenn deine Ehre mit Apple-Kritik angekratzt wird, aber ich muss dich enttaeuschen; ich sympathisiere kein Stueck mit google, der Beitrag hat sein Ziel daher wohl verfehlt.

  19. Re: Das ist wohl ein schlechter Scherz!

    Autor: /mecki78 10.02.17 - 16:07

    gaciju schrieb:
    --------------------------------------------------------------------------------
    > Das machst du doch genauso,

    Wo bitte soll ich das gemacht haben?

    > s. mein Beitrag weiter oben.

    Ich weiß nicht wer du bist und von welchen Beitrag du hier spricht. Ich hab hier noch nie auf einen Beitrag von dir geantwortet! Und nach dieser Anschuldigen werde ich das auch nicht mehr.

    *PLONK*
    (troll dich woandres)

    /Mecki

  20. Re: Das ist wohl ein schlechter Scherz!

    Autor: /mecki78 10.02.17 - 18:35

    gaciju schrieb:
    --------------------------------------------------------------------------------

    Den Beitrag meintest du?
    Auf den hatte ich doch gar nicht geantwortet!
    Den hatte ich doch bis jetzt noch nicht einmal gelesen.
    Oh, entschuldige das ich eine Leben hab und nicht 12 Stunden am Tag Golem Foren verfolge, damit ich dir sofort antworten kann, wenn du mir die Ehre gibst meinen Beitrag zu kommentieren. Hältst du dich ernsthaft für derart wichtig, dass du glaubst nur weil dir jemand nicht sofort antwortet ignoriert er deinen Beitrag absichtlich? Wow, na dann war der PLONK ja voll verdient.

    > Falsch. AMD, Intel und ImgTec wuerden liebend gern ihre Vulkan Treiber auch
    > unter MacOS und iOS bereitstellen.

    Niemand hindert sie daran das für macOS zu tun. Und ich glaube nicht, dass AMD oder Intel das für iOS tun wollen, denn iOS Geräte haben keine Grafikchips von AMD oder Intel.

    > Apple liefert die Treiber fuer MacOS (und iOS sowieso) selber mit aus,

    Und? Das hindert noch verbietet es irgendwen einen Treiber zu liefern, es macht es nur nicht zwingend erforderlich.

    > Microsoft nicht.

    Microsoft hat es schier der Unmenge an unterstützten GPUs, zu der jedes Jahr zig neue dazu kommen, es einfach aufgegeben. Noch dazu sind die die Treiber auf einer CD/DVD ja schon am ersten Tag veraltet, wenn das Ding aus dem Presswerk kommt. In Windows 95/98/ME z.B. waren diverses GPU Treiber dabei für Karten von NVidia oder ATI und die hatten alle "(c) Microsoft Cooperation" in den Metadaten stehen. Verwendet hat die aber aus vorher genannten Gründen keiner, die waren für den ersten Boot und dann hat man Internet eingerichtet und sich besser Treiber geholt.

    Apple hingegen muss ja nur das unterstützen, was sie verbauen. Die aktuellen GPUs die Apple verbaut kannst du zu jedem Zeitpunkt an zwei Händen abzählen, aktuell vielleicht sogar an einer (iOS/tvOS/watchOS mal außen vor).

    > Windows hat keine d3d Beschleunigung an Bord.

    Nimm einen Win 10 Installer DVD.
    Pack das Archiv /sources/install.wim aus.
    Du findest es unter: /1/Windows/System32/d3d10.dll

    Ob du Beschleunigung hast oder nicht, das hängt von deinem GPU Treiber ab, bzw. ob überhaupt einer genutzt wird, aber wenn du einen hast, dann hat Windows alles weitere sehr wohl schon "an Bord".

    > Das was Apple bisher vorgelegt hat, ist nichts
    > anderes als Metal + JavaScript.

    Spätestens hier hast du jegliche Glaubwürdigkeit verspielt. Ich zitiere mal den ersten Einleistungssatz auf der Seite zu WebGPU:

    This is Apple's draft proposal for the WebGPU API. It started as a mapping of Metal to JavaScript, but that won't be where it ends up. Not only are there some things in Metal that don't quite fit with Vulkan and D3D12, we also don't want to be tied to the Metal API. So please consider this a work in progress. There is a small source code example at the end (although it is a bit out of date).

    Also, woran liegt es bei dir?

    1. Zu faul überhaupt die Seite zu besuchen aber groß Sprüche klopfen?
    2. Englisch? Ja, da war mal was in der Schule aber für den Text reicht's nicht?
    3. Du verbreitest lieber "Alternative Fakten" weil die echten liegen dir nicht so?

    > Auch das ist falsch. WebGL basiert auf GLES.

    Und GL ES ist nur ein Subset von OpenGL. Wenn WebGL nur auf GL ES laufen würde, wie läuft es denn dann auf Desktop Systemen, die zwar OpenGL, aber kein GL ES anbieten? Deine Argumentation ergibt über weite Strecken nicht mal einen Sinn.

    > Du wirst lachen, aber Mozilla und Google verwenden fuer ihre Browser ANGLE,
    > was WebGL/GLES auf d3d mappt, weil es idR. besser performt.

    Nein, das tun sie, weil Windows ab Werk kein echtes OpenGL mitbringt, nur OpenGL 1.4 und das ist selber über D3D emuliert und daher auch nicht sehr performant. Und darauf, dass der Nutzer einen Grafikkartentreiber installiert hat, der eine vollwertige, und performante OpenGL Implementierung mitbringt, darauf können sich diese beiden Firma ja wohl schlecht verlassen, sonst müssten sie das als Hardwareanforderung ihrer Browser angeben. Sie haben also gar keine Wahl als WebGL über D3D abzubilden, denn was bitte wäre die Alternative? Und wieder mal fallen Worte aus deinem Mund, aber du kannst mir nicht erzählen dass du die durchdacht hast.

    > Bisher haben sie ueberhaupt gar nichts Brauchbares geschaffen, also Fuesse
    > stillhalten.

    Und das werden sie wohl auch nie, wenn Leute wie du alles was sie vorschlagen schon in Grund und Boden rammen am Tag der Vorstellung. Du gibst ihnen ja nicht mal eine Chance etwas zu entwickeln. Du sagst ja schon das es Schlecht ist, dabei ist da noch gar nichts außer ein Vorschlag.

    > d3d kann alleine schon aus lizenzrechtlichen Gruenden nicht mal eben
    > portiert werden, weil es proprietaer ist. Metal genauso.

    Und H.264 genauso... und dennoch wurde es auf fast jede aktuelle Plattform portiert. Wo hat denn Microsoft jemals gesagt, dass sie nicht bereit wäre die DirectX für andere Plattformen zu lizenzieren? Ich kann mich nicht erinnern, dass die das jemals gesagt haben. Auch hat Apple nie derartiges zu Metal gesagt. Rechtliche Gründe lassen sich immer beseitigen, technische Gründe sind wenn überhaupt unüberwindbare Hürden. Das ist rein technisch möglich ist, das hat ja WINE bewiesen.

    > So laeuft Doom etwa auf Linux,
    > obwohl es nur einen offiziellen Windows Client gibt.

    Doom läuft auf Linux weil es unter Linux auch eine Vulkan Implementierung gibt und die natürlich von der API her gleich ist. Aber deswegen ist sie vom Code noch lange nicht gleich. Natürlich gibt es auch ein paar portable Stellen im Vulkan Code, C ist C und so Dinge wie die SPIR-V Implementierung dürften nur Standard C sein, aber überall wo irgend eine Betriebssystemfunktion oder nicht Standard-C-API genutzt wird (glibc API oder Windows API) ist natürlich nicht portabel. Und Vulkan selber macht eben nicht mehr viel, Vulkan soll ja einen dünne Zwischenschicht sein, die eben möglichst wenig tut, das ist von Anfang an das Ziel gewesen. Hauptsächlich muss Vulkan mit dem Treiber der GPU sprechen und alleine dieses "sprechen" unterschiedet sich ja bereits gravierend zwischen den Systemen, was bitte soll da portable sein?

    Die Aussage "Doom läuft auch unter Linux" beweist also einfach mal so überhaupt nichts.

    /Mecki

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. über Nash Direct GmbH, München/Ismaning
  2. Daimler AG, Leinfelden-Echterdingen
  3. SCHOTT AG, Mainz
  4. Deutsche Telekom AG, Bonn, Münster

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. 299,99€ (Vorbesteller-Preisgarantie)
  2. (u. a. The Revenant 7,97€, James Bond Spectre 7,97€, Der Marsianer 7,97€)
  3. 38,49€ (Vorbesteller-Preisgarantie)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Creoqode 2048 im Test: Wir programmieren die größte portable Spielkonsole der Welt
Creoqode 2048 im Test
Wir programmieren die größte portable Spielkonsole der Welt
  1. Arduino 101 Intel stellt auch das letzte Bastler-Board ein
  2. 1Sheeld für Arduino angetestet Sensor-Platine hat keine Sensoren und liefert doch Daten
  3. Calliope Mini im Test Neuland lernt programmieren

Anker Powercore+ 26800 PD im Test: Die Powerbank für (fast) alles
Anker Powercore+ 26800 PD im Test
Die Powerbank für (fast) alles
  1. SW271 Benq bringt HDR-Display mit 10-Bit-Panel
  2. Toshiba Teures Thunderbolt-3-Dock mit VGA-Anschluss
  3. Asus Das Zenbook Flip S ist 10,9 mm flach

Microsoft Surface Pro im Test: Dieses Tablet kann lange
Microsoft Surface Pro im Test
Dieses Tablet kann lange
  1. Surface Diagnostic Toolkit Surface-Tool kommt in den Windows Store
  2. Microsoft Lautloses Surface Pro hält länger durch und bekommt LTE
  3. Microsoft Surface Laptop Vollwertiges Notebook mit eingeschränktem Windows

  1. Ipod Touch günstiger: iPod Nano und iPod Shuffle eingestellt
    Ipod Touch günstiger
    iPod Nano und iPod Shuffle eingestellt

    Apple hat den Verkauf der Musikplayer iPod Nano und iPod Shuffle eingestellt. Im Onlineshop werden die Geräte nicht mehr gelistet, andernorts gibt es noch Restbestände. Der iPod Touch wird günstiger verkauft.

  2. Nissan Leaf: Geringer Reichweitenverlust durch alternden Akku
    Nissan Leaf
    Geringer Reichweitenverlust durch alternden Akku

    Der Nissan Leaf ist vom ADAC fünf Jahre lang getestet und dabei 80.000 Kilometer gefahren worden. Das Elektroauto kam fabrikneu auf eine Reichweite von 105 Kilometern. Nun sind es 93 Kilometer geworden.

  3. Quartalsbericht: Amazons Gewinn bricht ein
    Quartalsbericht
    Amazons Gewinn bricht ein

    Amazons Gewinn ist um 77 Prozent zurückgegangen. Der Konzern hat erneut viel investiert. Jeff Bezos ist nur kurz der reichste Mann der Welt gewesen.


  1. 07:23

  2. 07:13

  3. 22:47

  4. 18:56

  5. 17:35

  6. 16:44

  7. 16:27

  8. 15:00