Skip to content

README.md

Latest commit

 

History

History
188 lines (138 loc) · 4.42 KB

README.md

File metadata and controls

188 lines (138 loc) · 4.42 KB
Raw

Aether

Ziel: Vulkan/DirectX12 Ersatz

Grundprinzip

Nicht fragen:

Wie mache ich eine einfachere API?

Sondern:

Welche Kosten haben Vulkan/DX12 heute noch, und wie eliminiere ich sie vollständig?

Performance-Ziele

1. Keine versteckte Arbeit

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.

2. Treiber fast eliminieren

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.

3. Pipeline-State vollständig vorkompiliert

Großer Vulkan-Nachteil: Pipeline Creation ist teuer. Lösung: Alle Pipelines werden offline erzeugt. Beim Spielstart: 0 ms Pipeline-Kompilierung.

4. GPU-native Befehle

Heute: API Command → Treiber Command → GPU Packet Stattdessen: API Command = GPU Packet

Der Command Buffer besteht direkt aus Hardware-Paketen. Das spart CPU-Zeit.

Radikaler Ansatz: Kein Treiber-Shading

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.

Speicherverwaltung: Komplett manuell

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.

Multithreading neu denken

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.

Shader-System: Datenorientiert

Nicht Material, sondern:

  • MaterialTable
  • TextureTable
  • SamplerTable

Alles als Arrays. Perfekt für Cache und GPU.

Bindless Everything

Heute: BindTexture(...) Aether Ansatz: texture_id = 523;

Shader greift direkt darauf zu. Keine Bind-Calls. Keine Descriptor-Sets. Nur globale Ressourcenpools.

GPU-Driven Rendering als Standard

Nicht optional. Alles läuft über:

  • Indirect Draws
  • Mesh Shaders
  • Compute Culling
  • GPU Scene Graph

CPU erzeugt praktisch keine Draw Calls mehr.

Moderne Features von Anfang an

  • Mesh Shaders
  • Task Shaders
  • Ray Tracing
  • Work Graphs
  • Sparse Resources
  • Bindless Rendering
  • Multi-GPU
  • Async Compute
  • Shader Execution Reordering

Nicht später hinzufügen.

Architektur-Idee

Aether API
│
├── Graphics
├── Compute
├── Raytracing
├── AI Accelerators
├── Video
└── Direct GPU Memory

Nicht nur Grafik, sondern komplette Beschleuniger-Hardware.

Noch aggressiver: GPU-first OS

Anwendung → Aether Runtime → GPU

Das Betriebssystem wird umgangen, soweit möglich. Ähnlich wie Konsolen oder spezielle HPC-Systeme.

Realistischer Entwicklungsplan

Phase 1

Eigenen Renderer bauen:

  • Vulkan Backend
  • DX12 Backend
  • Command-System
  • Resource-System
  • Pipeline-System

Phase 2

Eigene Abstraktionsschicht: Aether API → Vulkan / DX12 / Metal

Phase 3

Eigenen Shader-Compiler entwickeln. Orientierung an LLVM und Clang.

Phase 4

Eigenes GPU-Zwischenformat. Nach dem Vorbild von SPIR-V.

Phase 5

Mit GPU-Herstellern zusammenarbeiten. Dann entsteht daraus eine echte Alternative zu Vulkan.

Was Vulkan heute noch fehlt

Wenn man Vulkan von Grund auf neu entwerfen würde, wären die größten Änderungen:

  1. Komplett bindless
  2. Keine Descriptor Sets
  3. Keine Laufzeit-Pipeline-Erstellung
  4. GPU-native Command Buffers
  5. GPU-driven Rendering als Pflicht
  6. Speicherverwaltung auf Konsolen-Niveau
  7. Treiberlogik weitgehend offline
  8. Shader direkt auf Hardware optimiert
  9. Null versteckte Synchronisation
  10. 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.