Eingabe
minimp4 liest den MP4-Container. h264 interpretiert den Videostream und liefert Metadaten und Bildreihenfolge.
Überblick
Projektatlas · V, Vulkan und OpenCL
Zwei verbundene Projektpfade: hardwarebeschleunigtes Video mit Vulkan und portable Compute-Arbeit mit OpenCL – jeweils von der API-Erzeugung bis zur Anwendung.
Zwei Wege von Spezifikationen zur laufenden GPU-Anwendung
Kleine Repositories trennen API-Erzeugung, Datenformate, Speicher, Oberfläche und Anwendung. Der Vulkan-Video-Pfad spielt H.264 ab; der OpenCL-Pfad berechnet und visualisiert Partikel gemeinsam mit Vulkan.
Vulkan Video · MP4 bis Bildschirmausgabe
OpenCL · Registry bis Vulkan-Interop
v_vulkan_video
Videowiedergabe direkt über die GPU
Ein H.264/AVC-MP4-Player in V, der Vulkan Video zur Dekodierung nutzt, eine passende GPU auswählt und Darstellung, Größenänderung und Looping übernimmt.
Dekodierung
Die Vulkan-Bindings stellen die native API in V bereit. Der Player prüft das Videoprofil und wählt eine kompatible GPU.
Darstellung
GLFW erzeugt Fenster und Eingabe, Dear ImGui liefert die Oberfläche und VMA unterstützt den GPU-Speicher.
Orchestrierung
v_vulkan_video verbindet Parsing, GPU-Auswahl, Dekodierung, Timing, Resize, Präsentation und Looping.
opencl
Compute und Grafik auf derselben GPU verbinden
Generierte OpenCL-1.0–3.0-Bindings für V, typsichere Hilfen für Buffer, Bilder und SVM sowie ein Partikelsystem, in dem OpenCL und Vulkan Speicher und Synchronisation teilen.
Generieren
v_opencl_bindings liest die kanonische Khronos-Registry und erzeugt nachvollziehbare V-Bindings für OpenCL 1.0 bis 3.0.
Sicher verwenden
opencl ergänzt die vollständige Low-Level-API um optionale, typsichere Hilfen für Discovery, Buffer, Bilder, SVM, Events und Lebenszyklen.
Portabel validieren
CI prüft Laufzeitpfade unter Linux sowie ABI-Builds für macOS und Windows; GCC, Clang, MSVC und TinyCC werden abgedeckt.
APIs verbinden
Das Partikelbeispiel kombiniert OpenCL-Compute mit Vulkan-Darstellung, nutzt nach Möglichkeit gemeinsamen Speicher und Semaphore und fällt sonst auf Host-Staging zurück.
Warum jeder Baustein wichtig ist
Ein Videoplayer wirkt wie eine einzelne Anwendung. Tatsächlich löst er mehrere sehr unterschiedliche Probleme, die hier bewusst in verständliche, wiederverwendbare Projekte getrennt sind.
minimp4
Findet die Videodaten
Eine MP4-Datei ist ein Behälter. minimp4 findet darin Bilder, Zeitangaben und technische Metadaten – vergleichbar mit einem Inhaltsverzeichnis.
h264
Versteht die komprimierten Bilder
H.264 speichert meist nur Veränderungen zu anderen Bildern. Dieses Projekt liest die Regeln, Abhängigkeiten und Reihenfolge, die zum Rekonstruieren nötig sind.
v_vulkan_bindings + vulkan
Übersetzt zwischen V und dem Grafiktreiber
Vulkan spricht die Sprache der GPU. Der Generator hält tausende Definitionen aktuell; die Bindings machen sie aus V heraus sicher und reproduzierbar erreichbar.
vulkan_memory_allocator
Verwaltet knappen GPU-Speicher
Videobilder sind groß und müssen am richtigen Ort liegen. VMA nimmt der Anwendung fehleranfällige Speicherbuchhaltung ab.
glfw + imgui
Macht das Ergebnis bedienbar
GLFW verbindet Fenster, Bildschirm und Eingabe. ImGui liefert Kontrollen und Diagnoseoberflächen, damit aus der Pipeline ein benutzbares Programm wird.
v_vulkan_video
Orchestriert das Gesamtsystem
Der Player koordiniert Dateizugriff, Zeittakt, Referenzbilder, GPU-Warteschlangen, Darstellung und Fensteränderungen zu einem sichtbaren Video.
opencl
Macht Compute kontrollierbar
Die vollständigen Bindings bleiben zugänglich; eine optionale Eigentums- und Typschicht vereinfacht Buffer, Bilder, SVM, Events und Kernel-Aufrufe.
v_opencl_bindings
Hält die API reproduzierbar
Der Generator bindet die Ausgabe an feste Khronos-Eingaben und validiert die generierte Oberfläche über mehrere Plattformen und Compiler.
v_imgui_examples
Zeigt die Integration kompakt
Ein getestetes Beispiel verbindet V, Vulkan, GLFW und Dear ImGui als kurzen Einstieg in die Grafik-Toolchain.
Ein Bild durch die Strukturkette
Für technisch Interessierte: Ein einzelnes H.264-Bild wird nicht mit einem Funktionsaufruf „angezeigt“. Metadaten, Referenzbilder, GPU-Ressourcen und Synchronisation werden als miteinander verknüpfte Vulkan-Strukturen beschrieben.
StdVideoDecodeH264PictureInfoBildnummer, SPS/PPS-IDs, Picture Order Count und Flags beschreiben das H.264-Bild unabhängig von Vulkan-Ressourcen.
VideoDecodeH264PictureInfoKHR → pNextErgänzt Slice-Anzahl und Slice-Offsets und hängt die codec-spezifischen Angaben über pNext an die allgemeine Dekodierstruktur.
StdVideoDecodeH264ReferenceInfoBeschreibt jedes ältere Referenzbild, von dem P- oder B-Bilder abhängen. Ohne diese Historie kann die GPU das aktuelle Bild nicht rekonstruieren.
VideoDecodeH264DpbSlotInfoKHR → VideoReferenceSlotInfoKHRVerbindet H.264-Referenzdaten mit einem Slot im Decoded Picture Buffer und dessen konkreter Bildressource.
VideoPictureResourceInfoKHRZeigt über imageViewBinding auf das GPU-Bild und nennt kodierte Größe und Array-Layer. Dies ist der physische Ziel- oder Referenzspeicher.
VideoBeginCodingInfoKHRÖffnet den Videokodierbereich mit Session, Session-Parametern und aktiven Referenzslots. Optional folgt ein Session-Reset.
VideoDecodeInfoKHR → vkCmdDecodeVideoKHRBündelt Bitstream-Puffer, Bytebereich, Zielbild, aktuellen DPB-Slot und alle Referenzslots. Erst jetzt wird der Dekodierbefehl aufgezeichnet.
ImageMemoryBarrier2 + SemaphoreBarrieren wechseln Bildlayout und Besitz zwischen Video- und Grafikwarteschlange; ein Semaphor verhindert, dass die Grafik ein unfertiges Bild liest.
SubmitInfo → Draw → PresentInfoKHRDie Dekodierwarteschlange erzeugt das Bild, die Grafikwarteschlange zeichnet es in ein Swapchain-Bild, und vkQueuePresentKHR übergibt dieses an den Bildschirm.