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

Keine Notwendigkeit für neue Grafik-APIs

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Keine Notwendigkeit für neue Grafik-APIs

    Autor: Sammie 09.02.17 - 01:15

    Ich glaub, die Notwendigkeit solch einer API ist einfach nicht gegeben. Selbst heute könnte man mit WebGL und WebGL2 im Prinzip schon relativ brauchbare Sachen machen. Und obwohl es WebGL jetzt schon mehrere Jahre gibt, hat gerade im Bereich 3D noch kein namhaftes Gamestudio irgendwas erfolgreiches in Richtung Browsergames veröffentlicht, wo man derartige 3D-Grafik gebrauchen könnte. Und das hat viele Gründe, aber am wenigsten liegts an der Grafik-API - eher an allem drumherum.

    Der technische Aspekt ist da nur das eine. Angefangen von den diversen Javascript-Engines in den unterschiedlichen Browsern, die alle einen unterschiedlichen Funktionsumfang und unterschiedliche Performance aufweisen. Dann eben all das, was man zum Gaming bräuchte, wie ordentlich performante TCP-Sockets (statt overheadlastige Websockets), richtiges Threading, native 64bit Integers, crossbrowser Keyboardeingaben unter Fullscreen (wird von Safari "aus Sicherheitsgründen" geblockt, ist aber blöd, wenn man dann weder per Tastatur navigieren noch chatten kann ^^), zukünftige VR-Funktionen und performanten komprimierten ByteCode (Stichwort: WebAssemblys), der nicht erst zur Laufzeit kompiliert werden muss.

    Darüber hinaus wollen bisher auch die wengisten irgendwas in Plain-Javascript von grundauf programmieren. Die meisten WebGL-3D-Demos sind irgendwelche WebGL-Exporte aus Unity heraus, wo man eben gleich eine GameEngine mitgliefert kriegt. Wer will schon großartig das Rad neu erfinden. Aber auch das sind in der Regel mehr Techdemos als wirklich ernsthafte Spieltitel.

    Aber das Hauptproblem sind vorallem die Datenmengen. Halbwegs ordentliche Spiele brauchen Minimum gute 150MB an Texturen für ihre Objekte - nach obenhin je nach Komplexität praktisch keine Grenzen. Dazu dann noch Sounds und anderen binären Datenkram. Gedrosselt wird das aber schonmal durch die Tab-Speicherlimits, die derzeit bei 768 MB liegen. Übersteigt man diese RAM-Menge, schmiert der Tab ab.

    Und zum Cachen von Daten fehlt den Browsern einfach ein vernünftiges System, dass es erlaubt, zB socketübertragene Daten auf dem Userrechner zu speichern und dynamisch von dort zu laden, damit GameAssets nicht bei jedem Game-Start neu heruntergeladen werden müssen (Ladezeiten, Traffic).

    Und ja, das Speichern geht durchaus mit indexedDB, aber auch in jedem Browser mit unterschiedlichen Restriktionen - anfangen von lächerlichen 10 MB (IE) bis hin zu prozentualen Anteilen abhängig des verfügbaren Temp-Speicherns in anderen Browsern - und alles was in der indexedDB zu einer Domain gehört, wird auch bereits zum Tab-Speicher dazugezählt.

    Momentan wird die indexedDB in Chrome & Firefox so gehandhabt, dass 50% des freien Diskspeichers für die IndexedDB genutzt werden kann - pro Domain (group of origins) aber maximal 20% dieser Menge. D.h. wer nur noch 10 GB frei hat, der hat 5 GB Cache übrig, von dem 1 GB pro Domain maximal genutzt werden kann. Theoretisch zumindest... je nach Browser und Version kann dann aber ab einer gewissen Datenmenge auch noch eine (abschreckende) Sicherheitsabfrage vom Browser ausgelöst werden. Wann und ob das kommt, ist nichtmal genau reproduzierbar.

    Gelöscht wird dieser Cache jedenfalls dynamisch nach dem LRU-Prinzip (Last Recently Used), so dass automatisch die Daten,die am längst nicht genutzt wieder wieder (komplett domainbezogen) verschwinden, wenn neuere Anwendungen Platz brauchen. D.h. wenn die aus dem obigen Beispiel 5 GB voll sind, und eine neue Anwendung will was speichern, dann verschwinden zB die kompletten 1 GB einer anderen Anwendung, wenn diese am längsten nicht genutzt wurde - und dann müsste man sie wieder neu runterladen. Nicht schön, aber irgendwie muss man das Platzproblem ja lösen. ^^

    Das gesamtverfügbare Platz ist aber auch nicht crossbrowserübergreifend abfragbar (manche Browser erlaubens, manche nicht) - und natürlich bei jedem User je nach freiem Festplattenplatz immer unterschiedlich. Solang zumindest das Speicher-Verhalten nicht in allen Browsern identisch (und ohne Sicherheitsabfragen) abläuft (Chrome & Firefox verzichten glaub ich in ihren neusten Versionen endgültig drauf) und auch das Limit für den IE mal auf ein realistisches/zeitgemäßes Maß angehoben wird, ist die IndexedDB auch kein brauchbar-verwendbarer Standard.

    Daher sollte man, bevor man sich irgendwelchen parallelen Grafik-APIs neben WebGL widmet, erstmal um das ganze Drumherum kümmern und die JS-Engines in Sachen Funktionsumfang, Performance und Restriktionen mehr vereinheitlichen, damit eine vernünftige Basis besteht - oder wahlweise einfach überflüssige Javascript-Engines absägen und gemeinsam an einer globalen Engine arbeiten, die in allen Browsern zum Einsatz kommt und eine feste Basis garantiert ist.

    Dann würden die GamesEntwickler auch mal in Erwägung ziehen, von Flash auf WebGL zu wechseln - denn bei Flash hat man all diese Probleme eben nicht. Ein Code, der in jedem Browser und jeder Browserversion gleich läuft, wo es keine Crossbrowserprobleme und unterschiedliche Performance gibt, den man wahlweise als Browsergame, MobileApp oder Standalone-Executable kompilieren kann - das sollte das erklärte Ziel sein. Erst wenn das funktioniert, kann man über alternative Grafik-APIs reden, aber bis dahin braucht sowas schlicht niemand, solang der Unterbau nicht problemlos funktioniert.

    HTML5 & Javascript war eben nie für sowas wie Games konzipiert worden - und erst jetzt die letzten paar 2-3 Jahre bemerken die Browserhersteller erstmal so langsam, an was es so allem im Vergleich zu Flash fehlt - technisch hinkt man da gute 4-5 Jahre hinterher und das muss eben aufgeholt werden - je eher desto besser. Aber eben auch von allen Browsern - nicht nur von einem oder zwei, das ist eben das Problem. Wenn ein Entwickler vor der Wahl steht 80-90% der User mit Flash erreichen zu können, oder wahlweise ein WebGL-Game zu entwickeln, dass nur in Chrome funktioniert und in den anderen Browsern gar nicht läuft oder laggt, ists ja verständlich, dass keiner das Javascript-Gefrickel anfassen will - da verzichtet man ja auf nen riesigen Kundenstamm.

    Die Browser-Entwicklung geht die letzten 2-3 Jahre zwar in eine gute Richtung, aber das Ziel ist noch ein ganzes Stück entfernt. Nahzu alles der oben aufgezählten Sachen wird auch definitiv kommen und liegt als Working Draft beim W3C vor - nur wann genau es kommt und wann es wirklich ein crossbrowserübergreifender und damit nutzbarer Standard wird - das ist die spannende Frage - Fakt ist nur, es wird noch einige Jährchen dauern, denn schnell waren die beim W3C noch nie.

  2. Re: Keine Notwendigkeit für neue Grafik-APIs

    Autor: GeXX 09.02.17 - 09:01

    Mit hätte, würde, könnte usw. bin ich immer sehr vorsichtig. Ich habe schon oft private "Marktanalysten" gehört, die am Ende dann ganz falsch lagen. Oder sind Sie / bist Du in der Marktforschung tätig.

    Ich finde den Ansatz sehr gut. Und genaugenommen haben schon viele Unternehmen etwas probiert, bis Apple es in die Hand nahm und es vernünftig umsetzte.

    Lassen wir uns doch überraschen!

  3. Re: Keine Notwendigkeit für neue Grafik-APIs

    Autor: FreiGeistler 09.02.17 - 11:59

    Schön und gut.
    Aber hast du auch an die Nachteile gedacht, die deine Vorschläge mit sich brächten?

  4. Re: Keine Notwendigkeit für neue Grafik-APIs

    Autor: /mecki78 09.02.17 - 14:13

    Sammie schrieb:
    --------------------------------------------------------------------------------
    > Ich glaub, die Notwendigkeit solch einer API ist einfach nicht gegeben.
    > Selbst heute könnte man mit WebGL und WebGL2 im Prinzip schon relativ
    > brauchbare Sachen machen.

    Ja, kann man. Aber warum genau noch einmal soll ich mit mit X Polygonen bei 60 FPS zufrieden geben, wenn ich mit genau der gleichen Hardware auch 2*X Polygonen bei 60 FPS haben kann? Und das Problem ist dabei nicht das WebGL schlecht implementiert ist, sondern das Problem ist, dass WebGL konzeptionell wie OpenGL funktioniert und damit genauso wie die Grafikkarten ... vor 16 Jahren. Aber eben nicht so wie heutige Grafikkarten. Heutige Grafikkarten mit OpenGL anzusprechen ist eben so wie wenn du einen Porschemotor in einen Trabi baust. Sicherlich hast du dann den schnellsten Trabi der Welt, aber 250 km/h kannst du dennoch nicht damit fahren, weil er dir schon beim Beschleunigen auseinander fällt. Willst du wirklich sehen was in dem Motor steckt, dann brauchst du auch die passende Karosserie, Fahrgestell und Bereifung und dann erst kann er zeigen, was er wirklich drauf hat.

    /Mecki

  5. Re: Keine Notwendigkeit für neue Grafik-APIs

    Autor: MadMonkey 09.02.17 - 19:06

    /mecki78 schrieb:
    > Ja, kann man. Aber warum genau noch einmal soll ich mit mit X Polygonen bei
    > 60 FPS zufrieden geben, wenn ich mit genau der gleichen Hardware auch 2*X
    > Polygonen bei 60 FPS haben kann? Und das Problem ist dabei nicht das WebGL
    > schlecht implementiert ist, sondern das Problem ist, dass WebGL
    > konzeptionell wie OpenGL funktioniert und damit genauso wie die
    > Grafikkarten ... vor 16 Jahren. Aber eben nicht so wie heutige
    > Grafikkarten. Heutige Grafikkarten mit OpenGL anzusprechen ist eben so wie
    > wenn du einen Porschemotor in einen Trabi baust. Sicherlich hast du dann
    > den schnellsten Trabi der Welt, aber 250 km/h kannst du dennoch nicht damit
    > fahren, weil er dir schon beim Beschleunigen auseinander fällt. Willst du
    > wirklich sehen was in dem Motor steckt, dann brauchst du auch die passende
    > Karosserie, Fahrgestell und Bereifung und dann erst kann er zeigen, was er
    > wirklich drauf hat.

    Nonsense - moderne GPUs funktionieren immer Grunde immer noch gleich wie die alten, bloss mit zig Erweiterungen und Optimierungen und neuen Features. Der grosse Unterschied zwischen alt (OGL, D3D) und neu (D3D12 & Vulkan) ist vor allem der, dass weniger abstrahiert wird und ein direkterer Zugriff möglich ist. Heisst: als Entwickler kannst du tiefer gehen und dadurch in deinem konkreten Fall Dinge anders tun sodass du Performance gewinnst. Es ist aber nicht so, dass mit Vulkan und D3D12 plötzlich alles ganz anders funktioniert

  6. Re: Keine Notwendigkeit für neue Grafik-APIs

    Autor: /mecki78 10.02.17 - 16:01

    MadMonkey schrieb:
    --------------------------------------------------------------------------------
    > Nonsense - moderne GPUs funktionieren immer Grunde immer noch gleich wie
    > die alten, bloss mit zig Erweiterungen und Optimierungen und neuen
    > Features.

    Die alten GPUs hatten eine feste Renderpipeline, in Hardware. D.h. schon ab Werk stand fest was mit den Vektordaten und den Texturdaten passiert, die man dort hinein füttert. Es gab lediglich eine ganze Reihe von Stellschrauben, mit denen man das Verhalten anpassen konnte (z.B. ob Fog gezeichnet werden soll, in welchen Abstand, wie dicht, oder welches Shading verwendet werden soll, oder wie Texturen zu filtern sind, usw.) OpenGL und D3D diente hier nur dazu die Texturdaten zu laden, diese ganzen Stellschrauben nach Bedarf zu setzten und dann die Vektordaten in den Pipeline zu füttern.

    Bei den neuen gibt es das nicht mehr, da ist die Renderpipeline komplett flexibel und macht von sich aus gar nichts mehr als Daten von A nach B durchzureichen. Nur noch die Shader sorgen dafür, das überhaupt etwas gezeichnet wird. Ohne Shader sitzt du vor einen schwarzen Schirm, egal wie viele Texturen du geladen und Vertices du gefüttert hast. Zwecks abwärtskompatibel kannst du die Karten natürlich im alten Rendermdous betreiben, dann lädt der Treiber eine Reihe von Shandern, die das Verhalten der festen Renderpipeline nachbilden (und die alten Stellschrauben wieder anbieten), aber man kauft ja nicht eine neue Karte um sie dann nur im alten Kompatibilitätsmodus laufen zu lassen.

    Früher waren GPUs wie einfache DVD Player. Ein einfacher DVD Player kann nur MPEG2 Videos abspielen, weil man auf DVDs nur MPEG2 Videos findet. Oft hat er dafür extra einen Hardware MPEG2 Video Decoder Chip, dem man auf der einen Seite direkt den MPEG2 Video Stream füttert und der dann auf der anderen Seite fertige Bilder ausspuckt, die man so am Fernseher anzeigen kann. Wenn dieser Player ab Werk keine CDs mit MP3s abspielen kann, dann kann er es nicht und ich kann es ihm auch nicht beibringen. Was er kann, wie er funktioniert, das ist fest. Vielleicht könnte man die Firmware hacken und dann ihm auch andere Dinge beibringen, aber das ist eben nur genau das: Ein Hack.

    Heute sind GPUs wie eigene Computer. Im Grunde ist eine GPU heute auch nur eine CPU mit eigenen Speicher, in die man Programme laden kann, die dann dort Daten verarbeiten. Das müssen nicht einmal Grafikdaten sein, weil der GPU das egal ist und ein Shader auch Daten von einem Speicherbereich lesen und in einen anderen schreiben kann (wo dann die CPU die Daten später wieder ausließt), ein Shader muss nichts auf den Bildschirm zeichnen Nur dank dieser Umstellung ist ja so was wie OpenCL (also Computing auf der GPU) möglich. Wie du OpenCL mit einer GPU mit fester Renderpipeline machen willst, das zeigst du mir bitte mal.

    Also wenn man keine Ahnung von einem Thema hat, bitte nicht auch noch Unwahrheiten verbreiten, weil andere, nicht so technisch versierte Nutzer glauben dir das dann am Ende noch (die Versierten lachen nur über solche Posts).

    /Mecki

  7. Re: Keine Notwendigkeit für neue Grafik-APIs

    Autor: Sammie 22.02.17 - 14:48

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Ja, kann man. Aber warum genau noch einmal soll ich mit mit X Polygonen bei
    > 60 FPS zufrieden geben, wenn ich mit genau der gleichen Hardware auch 2*X
    > Polygonen bei 60 FPS haben kann?

    Trotzdem ist die Notwendigkeit dafür nicht gegeben, da man derartige Polygonmengen im Browser schlich nicht benötigt, da die Transfermenge der Daten für Objekte und Texturen schon heute den Rahmen sprengt, was ja auch ein Hauptgrund dafür ist, warum keine Sau irgendwas Größeres in WebGL macht.

    Nicht dass es technisch nicht ginge, aber die Limitierungen bzgl maximalen RAM pro Tab und dem fehlendem persistenten Caching der Daten, machen es schlicht unmöglich etwas Anspruchsvolleres direkt im Browser laufen zu lassen.

    Was bringts dir, im Browser ein Spiel wie GTA laufen zulassen, wenn dafür erstmal (bei jedem Spielstart) mehrere GB Texturdaten runtergeladen werden müssen, von den Objektdaten mal ganz abgesehen. Schon heut klickt ja jeder frustriert aufs X, wenns Ladezeiten gibt, wenn die Ladezeiten länger als 1-2 Minuten dauern. Zudem ist in Chrome bei 768 MB RAM pro Tab eben Schluss, egal wie viel man in der Kiste hat.

    Wer anspruchvollere Projekte veröffentlichen will, macht gleich ein Clientgame und kein Browsergame.

Neues Thema Ansicht wechseln


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

Anzeige
Stellenmarkt
  1. Pilz GmbH & Co. KG, Ostfildern bei Stuttgart
  2. MBtech Group GmbH & Co. KGaA, Stuttgart
  3. DLR Deutsches Zentrum für Luft- und Raumfahrt e.V., Braunschweig
  4. BG-Phoenics GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 56,08€ (Vergleichspreis ab ca. 65€)
  2. 18,01€+ 3€ Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


Kein App Store mehr: iOS-Nutzer sollten das neue iTunes nicht installieren
Kein App Store mehr
iOS-Nutzer sollten das neue iTunes nicht installieren
  1. Drei Netzanbieter warnt vor Upgrade auf iOS 11
  2. Betriebssystem Apple veröffentlicht Goldmaster für iOS, tvOS und WatchOS
  3. Apple iPhone 8 und iPhone 8 Plus lassen sich drahtlos laden

Inspiron 5675 im Test: Dells Ryzen-Gaming-PC reicht mindestens bis 2020
Inspiron 5675 im Test
Dells Ryzen-Gaming-PC reicht mindestens bis 2020
  1. Android 8.0 im Test Fertig oder nicht fertig, das ist hier die Frage
  2. Logitech Powerplay im Test Die niemals leere Funk-Maus
  3. Polar vs. Fitbit Duell der Schlafexperten

Energieversorgung: Windparks sind schlechter gesichert als E-Mail-Konten
Energieversorgung
Windparks sind schlechter gesichert als E-Mail-Konten
  1. Messenger Wire-Server steht komplett unter Open-Source-Lizenz
  2. Apache Struts Monate alte Sicherheitslücke führte zu Equifax-Hack
  3. Kreditrating Equifax' Krisenreaktion ist ein Desaster

  1. Wegen Lieferproblemen: Spekulationen über Aus für Opels Elektroauto Ampera-E
    Wegen Lieferproblemen
    Spekulationen über Aus für Opels Elektroauto Ampera-E

    Der Opel Ampera-E ist in Deutschland praktisch nicht lieferbar. Nun wird spekuliert, ob nach der Übernahme des Autoherstellers durch Peugeot das von GM produzierte Elektroauto gar nicht mehr angeboten wird.

  2. Minix: Fehler in Intel ME ermöglicht Codeausführung
    Minix
    Fehler in Intel ME ermöglicht Codeausführung

    Erneut soll es eine Sicherheitslücke in Intels Management Engine (ME) geben. Experten ist es nach eigenen Angaben gelungen, unsignierten Code auszuführen und Sicherheitsmechanismen zu umgehen.

  3. Oracle: Java SE 9 und Java EE 8 gehen live
    Oracle
    Java SE 9 und Java EE 8 gehen live

    Java geht in eine neue Runde: In Version 9 gibt es eine verbesserte Dokumentation und mit JShell eine interaktive REPL. Java EE 8 verbessert JSON und JAX-RS. Außerdem sollen OpenJDK und Oracle JDK ähnlicher werden.


  1. 15:30

  2. 15:06

  3. 14:00

  4. 13:40

  5. 13:26

  6. 12:49

  7. 12:36

  8. 12:08