Ziel: Vulkan/DirectX12 Ersatz
Nicht fragen:
Wie mache ich eine einfachere API?
Sondern:
Welche Kosten haben Vulkan/DX12 heute noch, und wie eliminiere ich sie vollständig?
Alles explizit. Vulkan geht schon stark in diese Richtung, aber nicht vollständig.
Beispiel:
Statt vkCmdBindPipeline(...) könnte der Entwickler direkt GPU-Objekte adressieren:
gpu_pipeline_id = 0x1234;Keine interne Suche. Keine Hashmaps. Keine Validierung.
Heute: Spiel → DX12/Vulkan → Treiber → GPU
Aether Architektur: Spiel → Runtime → GPU Firmware
Der Treiber wird fast nur ein Loader. AMDs Mantle verfolgte teilweise diese Idee.
Großer Vulkan-Nachteil: Pipeline Creation ist teuer.
Lösung: Alle Pipelines werden offline erzeugt. Beim Spielstart: 0 ms Pipeline-Kompilierung.
Heute: API Command → Treiber Command → GPU Packet
Stattdessen: API Command = GPU Packet
Der Command Buffer besteht direkt aus Hardware-Paketen. Das spart CPU-Zeit.
Heute: Shader (HLSL/GLSL) → SPIR-V → GPU ISA
Aether Lösung: Offline Compiler → Native GPU ISA
Das Spiel liefert bereits den finalen Maschinencode.
- Nachteil: Nicht portabel.
- Vorteil: Maximale Performance.
Vulkan: halb manuell Aether: vollständig manuell
Beispiel:
allocate_vram(
address = 0x40000000,
size = 128_MB
);Der Entwickler bestimmt die exakte VRAM-Adresse. Ähnlich wie Konsolenentwicklung.
DX12/Vulkan skalieren gut, aber nicht perfekt. Idee: Command Buffers komplett lockfrei. Jeder CPU-Kern schreibt direkt in einen eigenen Ring Buffer:
- Core 1 → Queue A
- Core 2 → Queue B
- Core 3 → Queue C
Später nur noch Zusammenführung. Keine Mutexes. Keine atomaren Hotspots.
Nicht Material, sondern:
MaterialTableTextureTableSamplerTable
Alles als Arrays. Perfekt für Cache und GPU.
Heute: BindTexture(...)
Aether Ansatz: texture_id = 523;
Shader greift direkt darauf zu. Keine Bind-Calls. Keine Descriptor-Sets. Nur globale Ressourcenpools.
Nicht optional. Alles läuft über:
- Indirect Draws
- Mesh Shaders
- Compute Culling
- GPU Scene Graph
CPU erzeugt praktisch keine Draw Calls mehr.
- Mesh Shaders
- Task Shaders
- Ray Tracing
- Work Graphs
- Sparse Resources
- Bindless Rendering
- Multi-GPU
- Async Compute
- Shader Execution Reordering
Nicht später hinzufügen.
Aether API
│
├── Graphics
├── Compute
├── Raytracing
├── AI Accelerators
├── Video
└── Direct GPU Memory
Nicht nur Grafik, sondern komplette Beschleuniger-Hardware.
Anwendung → Aether Runtime → GPU
Das Betriebssystem wird umgangen, soweit möglich. Ähnlich wie Konsolen oder spezielle HPC-Systeme.
Eigenen Renderer bauen:
- Vulkan Backend
- DX12 Backend
- Command-System
- Resource-System
- Pipeline-System
Eigene Abstraktionsschicht:
Aether API → Vulkan / DX12 / Metal
Eigenen Shader-Compiler entwickeln. Orientierung an LLVM und Clang.
Eigenes GPU-Zwischenformat. Nach dem Vorbild von SPIR-V.
Mit GPU-Herstellern zusammenarbeiten. Dann entsteht daraus eine echte Alternative zu Vulkan.
Wenn man Vulkan von Grund auf neu entwerfen würde, wären die größten Änderungen:
- Komplett bindless
- Keine Descriptor Sets
- Keine Laufzeit-Pipeline-Erstellung
- GPU-native Command Buffers
- GPU-driven Rendering als Pflicht
- Speicherverwaltung auf Konsolen-Niveau
- Treiberlogik weitgehend offline
- Shader direkt auf Hardware optimiert
- Null versteckte Synchronisation
- Datenorientiertes Design überall
Damit könnte man in bestimmten Workloads tatsächlich messbar schneller als Vulkan sein – um den Preis geringerer Portabilität, schwierigerer Entwicklung und der Notwendigkeit enger Zusammenarbeit mit GPU-Herstellern. Vulkan ist ein Kompromiss; dieses Design gibt viele Kompromisse bewusst auf für absolute Performance.