Minecraft Java Edition wechselt von OpenGL zu Vulkan
(minecraft.net)- Minecraft Java Edition stellt seine Grafik-Rendering-Engine von OpenGL auf Vulkan um
- Hintergrund des Wechsels sind die eingestellten Updates für OpenGL und das auslaufende macOS-Supportmodell
- Vulkan bietet native Unterstützung unter Windows und Linux, macOS wird über eine Übersetzungsschicht unterstützt – ohne Leistungseinbußen
- Durch die Umstellung werden bessere visuelle Qualität und höhere Bildraten erwartet
- In Snapshots werden OpenGL und Vulkan zunächst parallel getestet; ist die Stabilität gesichert, soll OpenGL entfernt werden
Bringing modern rendering to Java
- In Minecraft: Java Edition laufen weiterhin Vorbereitungen für Vibrant Visuals, während der Rendering-Code refaktoriert und modernisiert wird
- Frühere Updates haben bereits die Struktur des Rendering-Codes verbessert
- Nun beginnt die Phase, in der die zugrunde liegende Rendering-Technologie selbst ersetzt wird
- Die Rendering-Technologie des Spiels soll von OpenGL auf Vulkan umgestellt werden
- Ziel ist es, neue Möglichkeiten bei Grafik und Performance zu erschließen
- Es wird erwartet, dass dies Auswirkungen auf die Modding-Community und einige Spieler haben wird
What are we changing?
- Java Edition nutzt derzeit die OpenGL-Grafik-API, die in den 1990er-Jahren entwickelt wurde
- Seit der ursprünglichen Veröffentlichung basiert das Spiel auf OpenGL
- OpenGL wurde gewählt, weil damit Linux, Windows und macOS auf allen Betriebssystemen unterstützt werden konnten
- Das Spiel wurde so konzipiert, dass es auf nahezu jedem PC und Mac läuft
- OpenGL wird seit 9 Jahren nicht mehr aktualisiert, ist unter macOS deprecated und wird dort künftig nicht mehr lauffähig sein
- Für die Kompatibilität mit macOS musste man bei einer älteren OpenGL-Version bleiben, was die Modernisierung der Codebasis erschwerte
- Damit Java Edition weiterhin auf den meisten PCs einschließlich macOS und Linux laufen kann, ist die Abkehr von OpenGL notwendig
Introducing: Vulkan
- Vulkan ist eine Grafik-API, die seit mehr als 10 Jahren am Markt ist und von den wichtigsten Hardware-Herstellern breit unterstützt wird
- Unter Windows und aktuellem Linux wird Vulkan nativ unterstützt; auf macOS ist Unterstützung über eine Übersetzungsschicht möglich und funktioniert ohne Leistungseinbußen
- Langfristig eröffnet das mehr Potenzial für Performance-Verbesserungen und funktionale Erweiterungen
- Es schafft die Grundlage für die Umsetzung von Vibrant Visuals
- Bei GPUs, die älter als 10 Jahre sind, besteht die Möglichkeit, dass Vulkan nicht unterstützt wird
What does this mean for modders?
- Beim Wechsel von OpenGL zu Vulkan werden OpenGL-basierte Rendering-Mods betroffen sein
- Die Umstellung auf Vulkan dürfte mehr Aufwand erfordern als die Anpassung an gewöhnliche Releases
- Der Modding-Community wird empfohlen, ihre OpenGL-Abhängigkeiten zu reduzieren
- Nach Möglichkeit sollte die interne Rendering-API wiederverwendet werden
- Bei Bedarf sind auch direkte technische Gespräche mit dem Entwicklerteam möglich
- Technische Diskussionen finden im Vibrant Visuals Discord-Kanal statt
- Dabei handelt es sich nicht um einen Ankündigungskanal, sondern um einen Raum für tiefgehende technische Gespräche unter Entwicklern
What does this mean for players?
- Einige Mods könnten während der Umstellung betroffen sein
- Mod-Autoren werden Zeit für Updates benötigen
- In künftigen Snapshots sollen OpenGL und Vulkan parallel angeboten werden
- In Snapshots und stabilen Versionen soll der Renderer auswählbar sein
- Parallel dazu wird an Stabilität gearbeitet und die Zahl der Bugs minimiert
- Bugs sollen über bugs.mojang.com gemeldet werden
When is this happening?
- Ziel ist es, Vulkan im Sommer in die Snapshot-Tests einzuführen
- Während der Testphase soll zwischen OpenGL und Vulkan gewechselt werden können
- Sobald Stabilität und Performance verifiziert sind, soll die OpenGL-Implementierung entfernt werden
- Vor der Entfernung wird es eine Vorankündigung geben
- Die Mindestanforderungen sollen aktualisiert werden
Vulkan and Vibrant Visuals
- Die Modernisierung des Renderers ist ein zentraler Schritt in der Vibrant-Visuals-Roadmap
- Der Wechsel zu Vulkan schafft mehr Spielraum für Grafikverbesserungen und stärkt die Performance-Basis
- Es wird erwartet, dass treiberbedingte Bugs zurückgehen
- Ein zentrales Ziel ist es, die dauerhafte Lauffähigkeit unter macOS sicherzustellen
- So soll gewährleistet werden, dass Spieler auf allen unterstützten Betriebssystemen gleichermaßen teilnehmen können
Bedeutung des Updates
- Diese Umstellung ist ein wichtiger Schritt dafür, dass Minecraft Java auf einen modernen Grafik-Technologie-Stack wechselt
- Sie stärkt die technische Grundlage der Spiel-Engine und schafft eine Struktur, die künftige Erweiterungen und neue Funktionen begünstigt
- Der Wechsel von OpenGL zu Vulkan passt außerdem zum branchenweiten Generationswechsel bei Grafik-APIs
3 Kommentare
Hacker-News-Kommentare
Hoffentlich sinkt mit der Zeit der CPU-Overhead des Main-Threads.
Spiele, die von DX11 auf 12 oder von OpenGL auf Vulkan portiert wurden, haben ihre Leistungsgewinne nicht einfach nur durch den API-Wechsel erzielt, sondern weil sie die parallele Verarbeitung von Draw Calls nutzen konnten.
Bei Minecraft entsteht der Flaschenhals dadurch, dass die CPU langsamer ist als die GPU rendern könnte; ich hoffe, dass diese Änderung auch in Modding-Umgebungen CPU-Reserven schafft.
Aus Spaß habe ich die Windows-Version unter Proton laufen lassen, und die Leistung war 30 % höher.
Ich vermute, das liegt am Multithreading der von Proton verwendeten dxvk-Bibliothek.
Ich finde es eine gute Entscheidung, dass Minecraft Java Edition nur für den Desktop gedacht ist und damit die Vulkan-Treiberprobleme auf Mobilgeräten vermeiden kann.
Andererseits hätte ich bei einem Unternehmen von der Größe Microsofts erwartet, dass es die Ressourcen hat, ein plattformübergreifendes RHI mit stabilen APIs je Plattform (DX12, Metal) zu bauen.
Drei Versionen des Java-Renderers zu pflegen, wäre eine große Belastung, und gerade weil das Modding-Ökosystem zentral ist, wird schon diese Änderung genug Verwirrung stiften.
Ich finde nicht, dass man die Wartung von Shader-Mods noch schwieriger machen sollte.
Vulkan kann auch auf macOS laufen, daher sehe ich nicht wirklich einen Grund, für neue Projekte extra DX12 zu verwenden.
Auf meinem alten Acer C720 Chromebook (Intel HD4400 iGPU) wird Vulkan nicht unterstützt, daher könnte Minecraft damit kaputtgehen.
Früher war es ein großer Vorteil, dass es auf praktisch jeder Hardware lief; das wäre schade.
Ich frage mich, warum die Kommentare nicht zum Quellbeitrag verschoben werden (zugehöriger Thread).
Interessant, dass Microsoft den Khronos-Standards inzwischen näher steht als Apple.
SPIR-V wurde als Ausgabe- und Eingabeformat des DirectX Shader Compilers übernommen, um die Interoperabilität mit Vulkan zu verbessern.
Apple war sehr unzufrieden damit, wie OpenCL behandelt wurde, und Sony sowie Nintendo interessieren sich kaum für Khronos.
Tatsächlich leiden die Khronos-APIs wegen des Problems des Erweiterungs-Spaghetti unter mangelnder vollständiger Portabilität.
VulkanMod bringt große Leistungsgewinne, ist aber mit den meisten Mods nicht kompatibel.
Wenn man Vulkan künftig auch in kompletten Modpacks verwenden kann, wäre das wirklich spannend.
Hoffentlich kommt Vibrant Visuals bald auch für die Java Edition.
Es ist schade, dass man für Shader immer Mods braucht.
Die Installation ist per Drag-and-Drop einer .zip-Datei möglich, ganz ohne komplexen Loader oder Sicherheitsrisiken.
Es ist zwar weniger flexibel als Aperture, Iris oder Optifine, aber funktional ziemlich ähnlich.
Ich frage mich, ob man auch Vulkan-Shader in Ressourcenpakete einbinden kann. Allerdings könnte das zu stark eingeschränkt werden, weil die Gefahr größer ist, Spielfunktionen zu beschädigen.
Ich wusste nicht, dass es Vulkan-Bindings für Java gibt. Vermutlich läuft das über JNI.
Überraschend, dass überhaupt noch OpenGL verwendet wurde. Ich kenne den aktuellen Zustand von Minecraft nicht gut, und dass es eine Desktop-Version außerhalb von Java gibt, wusste ich auch nicht.
Das Speichermanagement ist deutlich sauberer, und Bindings an externe Funktionen (wie Vulkan) werden viel einfacher.
Meiner Meinung nach ist das eine der am meisten unterschätzten Funktionen des modernen Java.
Ich frage mich, warum man zwei Versionen desselben Spiels pflegt.
Bedrock hat funktional fast aufgeholt, aber als vollständiger Ersatz ist es gescheitert.
Bedrock hat zwar Vorteile bei Leistung und Portabilität, aber auf Konsolen ist Modding ohnehin nicht möglich.
90 % der YouTube-Inhalte basieren auf Java, deshalb konzentriert sich Microsoft darauf, Funktionsgleichheit herzustellen.
Aus Microsofts Sicht ist es sinnvoll, beide Versionen weiterzuführen, um den Umsatz zu maximieren.
Hoffentlich wurde das Problem der Verzögerung durch Vulkan-Shader-Kompilierung gut gelöst.
Er ist kein komplexes Materialsystem, sondern ein einfacher Voxel-Renderer.
Probleme entstehen, wenn die Engine zu viele Shader-Kombinationen erzeugt oder wenn bestimmte GPU-Zustände (z. B. Blending) eine Neukompilierung der Shader auslösen.
In modernem Vulkan kann der Großteil dieses Zustands als dynamischer Zustand (dynamic state) behandelt werden, was das Problem entschärft.
Einige Zustände wie Blending können allerdings weiterhin eine Neukompilierung verursachen.
Das heißt: Wenn Entwickler solche dynamischen Zustände vermeiden, lassen sich die Verzögerungen leicht verhindern.
Große Spielestudios vernachlässigen technische Optimierung heutzutage oft.
Minecraft wurde ursprünglich in Java entwickelt, und nachdem es an Microsoft verkauft wurde, scheint es noch einmal in C++ umgesetzt worden zu sein. Ein ganzes Spiel vollständig in einer anderen Programmiersprache neu zu implementieren, dürfte keine leichte Aufgabe gewesen sein – ich finde es faszinierend, wie es dazu gekommen ist.
Sie scheinen die Bedrock-Edition wohl für die Optimierung auf Mobilgeräten entwickelt zu haben …
Ich dachte, sie würden Java vielleicht aufgeben, aber am Ende sieht es so aus, als würden sie beide weiter aktualisieren.