Asteria v0.3.0 — Native Vulkan Release

Asteria v0.3.0 — Native Vulkan Release

Asteria v0.3.0 introduces live native Vulkan presentation for Experimental PyroWave streaming. Supported GPUs can keep decoded video GPU-resident through BT.709 color conversion and presentation, avoiding the previous synchronous CPU I420 readback and D3D11 video upload path. Native overlays, bounded GPU frame management and initialization-time fallbacks accompany this change. Normal H.264, HEVC and AV1 streaming is retained.

Highlights

• Native Vulkan presentation for live PyroWave on supported Windows hardware.
• Decode and presentation share one Asteria-owned Vulkan device.
• Three video slots with GPU-safe retirement of dropped, unpresented frames.
• Native debug/status overlays and retained-frame redraws, including overlay-only updates.
• Resize, minimize/restore, maximize and fullscreen/windowed lifecycle handling, reconnect support and clean session teardown.
• Qualified BT.709 FULL/LIMITED conversion with CENTER chroma presentation.
• Normal Windows x64 and native ARM64 portable packages with pinned runtime, shader provenance, symbols and corresponding source.

Native Vulkan PyroWave

Select PyroWave (Experimental) explicitly when connecting to a compatible Vibepollo host. Automatic continues to choose standard codecs only. Native Vulkan is preferred when initialization proves the required device features, image usage, synchronization, borrowing and presentation capabilities.

On the previous Surface path, Vulkan decode was followed by synchronous CPU I420 readback, D3D11 texture upload and SDL/D3D11 presentation. The new preferred path is:

PyroWave Vulkan decode on Asteria's device
 -> caller-owned GPU-resident Y/U/V
 -> qualified Vulkan BT.709 conversion
 -> native Vulkan swapchain
 -> display

The native video path uses no CPU video readback, external memory/semaphore handles or D3D11 video resources. Initialization-time legacy GPU interoperability and compute/CPU-I420 fallbacks remain available where native Vulkan cannot initialize. A fatal native error during streaming ends that stream through normal cleanup; it does not silently change backends.

Native Vulkan is specific to PyroWave in this release. It is not used for every codec or guaranteed on every GPU/driver.

Streaming and compatibility

H.264, HEVC, AV1, Automatic selection, audio/input and the existing codec-aware bitrate settings retain their behavior. The PyroWave profile covered here is SDR, 8-bit, 4:2:0, BT.709, CENTER chroma. Stage 4 separately qualified FULL and LIMITED; the first Stage 5 live log verified FULL range, with no precise LIMITED-range live evidence recorded.

PyroWave remains pinned to commit 186f0393b77f7755953b5ecde994bb1cec2e4155, bitstream 186f0393, C API 0.6.0; Granite remains b6cffd5ce81f540f0855e6778428483e14763d9b. Approved local patches, borrowed-device cleanup, strict DLL hashing/provenance and restricted runtime loading are retained.

Windows x64 / ARM64

Use the x64 package on Intel/AMD Windows PCs, or the native ARM64 package on Windows-on-ARM hardware. Both use the established unsigned Release build configuration and include the required Qt/SDL/codec dependencies and notices. No Vulkan SDK, bundled Vulkan loader or runtime shader compiler is required; native Vulkan uses the installed Windows GPU driver.

Stage 5 live native Vulkan was owner-qualified on Surface Pro 11 / Snapdragon X Plus / Qualcomm Adreno X1-85, using normal ARM64 Asteria and normal Vibepollo. The first live log at qualified implementation 5c7ec593d9c5c27b097d194ea758b48b09a2bba4 verified fragment decode, all borrowed-device handle matches, zero CPU video readbacks/external handles/D3D11 resources, 93 safely retired presentation drops, bounded slot reuse and clean teardown.

Five reconnect cycles in the same process, window transitions, functional overlay-only updates, standard-codec streaming and audio/input across reconnects are separately owner-confirmed. The first log recorded overlayRedraws=0; additional machine counters or logs are not asserted. Hosted GPU tests and Vulkan validation were unavailable and recorded as SKIP, not hardware or validation PASS. The owner also confirmed final normal ARM64 release-package smoke on exact source 2f29a8963078dadbe4e5031791a6390098e4635d / portable ZIP SHA-256 4754bf1cf7c6809aa8877fd379a6c04a978f23788d8175cbf4d0b26d75f82791: launch, native PyroWave video, audio/input, debug overlay, no fatal errors, clean disconnect and standard-codec streaming passed. This is owner functional sign-off; no additional machine counters or log verification are claimed. Broader GPU and x64 native-path hardware coverage remains separate.

Performance observations

An initial Surface screenshot at 2560x1440 sampled about 119.91 incoming, decoding and rendering FPS. Its individual timing scopes were:

Measurement	Sample
Decode CPU API / asynchronous submission	0.38 ms
Frame queue delay	0.34 ms
Rendering CPU time	0.27 ms
Shutdown GPU iDWT fragment timing	1.886 ms/frame
Shutdown GPU Dequant timing	0.782 ms/frame

CPU API/submission time is not total GPU decoding time. These samples are neither a matched comparison with the old fallback nor an end-to-end/scanout latency measurement. There is no universal 120 FPS or latency guarantee, and PyroWave is not claimed to outperform HEVC or AV1 generally. Controlled performance qualification and v1.0 polish remain the next development phase.

Experimental feature limitations

• Native Vulkan availability depends on hardware and driver capabilities.
• PyroWave stays Experimental and explicitly selected; the Asteria release channel does not graduate the feature.
• PyroWave HDR, 10-bit, 4:4:4 and BT.2020 are outside this implementation.
• No calibrated ICC/display-color-management or general end-to-end latency guarantee.
• Broader compatibility, long-run resource/performance behavior and forced physical GPU-loss recovery remain separate qualification work.
• Vulkan validation was unavailable on the owner configuration and remains SKIP.

Known issues

The tested Qualcomm driver rejects legacy Vulkan/D3D11 shared-fence import. Native Vulkan avoids that interoperability requirement on the qualified configuration; existing compute/CPU-I420 fallback remains available when native initialization is unsupported. The native success run did not exercise those fallback paths.

Packages are unsigned portable ZIPs. This release does not ship an installer, MultiSeat or VR, and does not add automatic diagnostic uploads. Report problems with the selected backend, source/package identity and sanitized logs; omit pairing data, credentials and private host details.

Installation

Download Asteria-v0.3.0-windows-x64-portable.zip or Asteria-v0.3.0-windows-arm64-portable.zip. Extract into a writable folder and keep portable.dat beside Asteria.exe. Keep all bundled dependencies together; launch Asteria normally and pair/authenticate manually.

Asteria's release identity is v0.3.0 — Native Vulkan Release. The inherited Moonlight application/version display remains 6.2.0; it is not the Asteria release tag.

Verification

SHA256SUMS.txt covers the exact final portable, symbols, source and evidence asset bytes for both architectures. For example:

Get-FileHash .\Asteria-v0.3.0-windows-arm64-portable.zip -Algorithm SHA256

Compare the result with the checksum file. The accompanying evidence records the release source SHA, run IDs, executable source revision, runtime/shader provenance and PE inventory. The bundled verify-stage5-owner-package.ps1 additionally verifies the extracted package against that exact source/architecture and original ZIP hash. Package manifests bind identity; hardware approval is recorded separately in the release evidence.

Both architectures are built from release source 2f29a8963078dadbe4e5031791a6390098e4635d, using Windows baseline run 38091218299. Matching symbols and source snapshots include recursive submodules and the existing dependency/build provenance. Historical v0.2.0 release assets and notes remain intact.

Credits / upstream acknowledgments

Asteria derives from Moonlight PC and retains its v6.2.0 baseline, history and licensing. Thanks to the Moonlight/common-c, PyroWave, Granite, Qt, SDL, FFmpeg and other dependency contributors, and to the Surface owner for functional qualification. Preserve all bundled licenses/notices and corresponding-source obligations. This release does not constitute an independent security audit or a new upstream dependency update.

Asteria v0.2.0

Asteria v0.2.0

Asteria v0.2.0 adds live Experimental PyroWave, improves streaming settings and branding, and advances the Moonlight upstream baseline while retaining native Windows x64 and ARM64 packages.

Highlights

• Live Vibepollo PyroWave SDR 8-bit 4:2:0 streaming, bundled in the normal x64 and ARM64 packages.
• Codec-aware bitrate limits, PyroWave automatic bitrate calculation and persistent manual overrides.
• Codec selection beside Resolution/FPS in Basic Settings.
• Final Moonlight PC v6.2.0 baseline, updated Windows dependencies and input fixes.
• Finalized Asteria logo and application icons, plus expanded automated qualification and review-only upstream tracking.

PyroWave

Select PyroWave (Experimental) explicitly. Automatic continues to select standard codecs only. No separate Asteria-P1a-Experimental download is needed.

The validated live profile is SDR, 8-bit, 4:2:0 with BT.709 full or limited range. The bundled codec/runtime is pinned to 186f0393b77f7755953b5ecde994bb1cec2e4155, bitstream ID 186f0393, API 0.6.0, with strict runtime/provenance validation and Vibepollo compatibility framing. Parser/runtime/live-frame validation, malformed-frame recovery, safe runtime failure handling, performance-overlay integration and native GPU timing diagnostics have been added.

Asteria attempts GPU presentation where supported. On the tested Surface Pro 11 / Snapdragon X Plus / Qualcomm Adreno X1-85, Vulkan/D3D11 shared-fence import returns PYROWAVE_ERROR_UNSUPPORTED_EXTERNAL_HANDLE. Asteria safely recreates the decoder for compute-path decode plus CPU I420 readback/presentation. This fallback works; the limitation is external-resource synchronization/interoperability, rather than an inability to decode PyroWave.

Owner validation on native ARM64 Asteria with a Vibepollo host at 2560×1440, up to a 120 Hz target, covered negotiation, decoding, rendering, audio and input. Workload FPS varied. This is one named workload/device, not a universal benchmark, end-to-end latency measurement or performance guarantee.

Streaming / Settings

• Automatic, H.264, HEVC and AV1: up to 500 Mbps; PyroWave: up to 3000 Mbps.
• Removed the old “Unlock bitrate limit (Experimental)” checkbox.
• PyroWave automatic bitrate uses approximately width × height × fps × 1.6 bits/s (1.6 bits/pixel/frame).
• Manual bitrate overrides survive resolution/FPS changes. Codec changes preserve valid manual values and clamp only values exceeding the new codec ceiling.
• Codec selection is now in Basic Settings beside Resolution/FPS. New installs default to 1080p; existing saved dimensions remain in effect.
• Enter and Numpad Enter are distinguished with compatible host software; keyboard-release state regression coverage has been added.

Moonlight v6.2.0 sync

The upstream baseline is the final Moonlight PC v6.2.0 release, de2467e433821664cdd2224aad8c89a625be1ad9, integrating the remaining upstream changes while preserving Asteria behavior. The original import already contained most pre-release development; the late upstream delta is 17 commits, not the entire Moonlight v6.2.0 changelog.

Relevant Windows changes include dependency refreshes and FFmpeg/SDL/OpenSSL fixes, input cleanup, Enter/Numpad Enter handling, the 1080p new-install default and build fixes. Asteria includes the corresponding security fixes from its full Moonlight v6.2.0 baseline for CVE-2026-33546, CVE-2026-33547 and CVE-2026-41210. Some were already inherited before the late delta; this is not an independent Asteria security audit. See Moonlight’s release notes.

Windows / ARM64 and branding

Both Windows x64 and native ARM64 are shipped as unsigned portable ZIPs, with recursive PE architecture checks. Native ARM64 was already established before v0.1.0; this release preserves it and adds bundled PyroWave. Hardware qualification remains limited, primarily to the named Surface Pro 11 for live ARM64 PyroWave.

The finalized logo appears in the application, Windows executable, Qt/window/taskbar and portable package resources. WiX/installer artwork and README branding assets are updated; this release distributes portable ZIPs, not an installer or an unrelated UI redesign.

Build / CI / Maintenance

Windows dependencies now use hash-verified moonlight-qt-deps v19 x64/ARM64 archives. Expanded coverage includes PyroWave parser, runtime/provenance, live-frame, presentation, queue/stats and GPU-presentation tests; settings persistence/UI and keyboard/input regressions; branding/icons; package architecture; bundled codec validation; and startup/import checks. Hosted tests do not establish broad GPU compatibility or physical-device-loss behavior.

Weekly Moonlight upstream tracking watches master, proposes history-preserving sync PRs and reports conflicts/manual-review cases. It never auto-merges or resolves conflicts unsafely. This is maintenance infrastructure, not runtime behavior.

Roadmap priorities are measured codec/performance work, native Vulkan PyroWave presentation, isolated sessions / MultiSeat, then Asteria VR. Old M2–M4 Apollo convenience milestones are deprioritized; useful plumbing may return later. These are future plans, not shipped features.

Known limitations

• PyroWave remains Experimental, not production-stable. The validated live path is SDR 8-bit 4:2:0; PyroWave HDR and 4:4:4 are not implemented.
• Native Vulkan PyroWave presentation is planned post-v0.2.0 and is not included.
• The tested Qualcomm driver uses compute + CPU I420 fallback because Vulkan/D3D11 shared-fence import is unsupported. Broad GPU/hardware compatibility and shared GPU-path performance remain unqualified.
• Isolated sessions / MultiSeat and VR are not implemented. Generic Apollo clipboard, server commands and virtual-display control UI are not shipped.

Downloads / verification

Use Asteria-v0.2.0-windows-x64-portable.zip for Intel/AMD Windows PCs, or Asteria-v0.2.0-windows-arm64-portable.zip for native Windows-on-ARM devices. Extract into a writable folder and keep portable.dat beside Asteria.exe.

Matching symbols, corresponding source snapshots including recursive submodules, and build/architecture evidence are provided for each architecture. Verify downloads against SHA256SUMS.txt, for example with PowerShell:

Get-FileHash .\Asteria-v0.2.0-windows-arm64-portable.zip -Algorithm SHA256

The project release is v0.2.0; the inherited application version remains 6.2.0. Exact release commit, qualification run IDs and portable hashes are recorded in the accompanying release evidence and the repository’s validation record.

Release qualification

Release commit and tag target: 42f756e465288157608fe894e3a3dfe800b05344. Windows x64/native ARM64 candidate and upstream comparison jobs passed in run 37262907765; both PyroWave jobs passed on the same commit in run 37263855400.

Portable SHA-256:

• x64: 50977afd156f0fca6c216ce120e6b2e84a0442e0377828ba09c71f8f8a2ad5b0
• ARM64: 65c1538c327e2358b7f74dc5353c73848ad95c007a93cbc49ef688fd92e7b53c

Assets are the exact qualified outputs, renamed without rebuilding. Release-status documentation follows publication in a documentation-only commit; binaries and source remain tied to the tag above. Full v0.1.0…v0.2.0 comparison.

Asteria v0.1.0

Asteria is a Windows game-streaming client derived from Moonlight PC. This is its first public, unsigned preview. Apollo is the project's target host.

Download the x64 or native ARM64 portable ZIP for your Windows device, extract it into a writable folder, and run Asteria.exe. Keep portable.dat in the extracted folder. No installer is included.

Both portable packages were built from commit 34dfd93 in the same successful Windows baseline run (36191650824). The release also includes SHA-256 checksums, symbols, corresponding source with pinned submodules, and architecture/build evidence. The portable ZIPs include source notices and license files.

The owner verified native ARM64 process execution on a Surface Pro 11th Edition with Snapdragon X Plus and 16 GB RAM. In repeated Apollo AV1 streams at 2560×1440 and approximately 60 FPS, native ARM64 Asteria showed stream parity with official x64 Moonlight running under Windows ARM64 emulation on the same device. Asteria's menus and settings felt smoother and snappier to the owner; this is a qualitative observation, not a timed benchmark. The owner also confirmed the completed x64 and ARM64 CI builds work. Exact OS build, driver, decoder, Apollo version, run duration, and tested artifact hashes were not recorded for the earlier comparison, so these observations are limited to the reported setup and should not be read as broad hardware qualification.

PyroWave, Apollo-specific extensions, profiles and additional session workflows, and Asteria VR are planned but not implemented. Inherited HDR, AV1, and hardware decoding paths depend on the host, client GPU, and drivers. Report reproducible issues in this repository.

Asteria retains Moonlight PC history, attribution, notices, licenses, and corresponding-source obligations. The internal application/package version inherited from the Moonlight baseline is 6.1.0; v0.1.0-preview.1 is Asteria's public preview tag. The bundled provenance file calls the build a development baseline because broad hardware qualification remains open; this release is a limited, unsigned preview.