Vkd3d mali#1
Open
utkarshdalal wants to merge 20 commits into
Open
Conversation
…rToImage2 uploads
…ped with CPU fallback
WRAPPER_ASTC_BLOCK=8x8 stores emulated BC textures as ASTC 8x8 (2 bpp, a quarter of 4x4's footprint) instead of the default 4x4. Each 8x8 block packs a 2x2 group of BC blocks and fits a 4x4 weight grid to the 64 ideal texel weights via the infill pseudo-inverse. Both the CPU encoder and the transcode compute shader now emit the 8x8 form (selected per-dispatch by an astc8 push constant); the shader's float weight-fit is bit-identical to the CPU double encoder, validated offline over 8000 blocks against Mesa's ASTC decoder. This removes the load-time memory thrash that 4x4 hit on Mali while keeping the GPU transcode path, so large BC7 texture sets upload fast and stay small.
The GPU compute transcode is correct in isolation — its BC7 decode is bit-identical to bcdec across all eight modes and the ASTC encode matches the CPU encoder — but injecting compute dispatches inline into vkd3d's command buffers corrupts Hades's launch-screen rendering (the screen goes black). The boot is dominated by the game's own package load rather than by transcode, so the GPU path saves no meaningful time here. Default WRAPPER_BCN_GPU to 0 (CPU, correct everywhere); set WRAPPER_BCN_GPU=1 to opt back into the GPU path.
WRAPPER_DIAG=1 emits a self-contained report at vkCreateDevice, to stderr (logcat) and to WRAPPER_DIAG_FILE: device/driver/engine identity, what the device NATIVELY supports vs what the wrapper advertises to the D3D layer (robustness2, vertex_attribute_divisor EXT/KHR, BC/ASTC, forced features), and the extensions the app requested at device creation. This lets a failing game on any device be diagnosed from the shared report alone, paired with app-side VKD3D_DEBUG=warn / DXVK_LOG_LEVEL=info / WINEDEBUG=+vulkan. Off unless WRAPPER_DIAG is set; zero cost otherwise.
Write the diagnostics report to /data/data/app.gamenative/files/imagefs/usr/tmp/wrapper_diag_<appid>.txt, named by WRAPPER_DIAG_APPID (falling back to the sanitized executable name) so multiple games each get their own file instead of clobbering one. The chosen path is echoed to logcat; WRAPPER_DIAG_FILE still overrides it.
A single launch creates several VkDevices across processes (zink GL infra, DXVK, vkd3d) that share one per-game report file. Opening it with "w" truncated per process, so they clobbered each other and the D3D device's block -- the one needed to debug a failing game -- was routinely lost to a later zink device. Append instead; each block is delimited and names its engine, and usr/tmp is recreated per launch so the file stays one launch's worth.
WRAPPER_DIAG_TEX=1 records, for each BCn CPU upload, the real parameters (source stride, target format, and the destination image's format / extent / mip count / tiling / usage / flags) and dumps the leading source BC7 bytes plus our transcode output to wrapper_tex_<appid>.txt. This localizes a corrupt- texture case (e.g. Xclipse renders BC7 as static even via RGBA-CPU): the transcode can be verified byte-for-byte offline against the reference decoder, and any stride/format/tiling mismatch in how the image is uploaded becomes visible. Off unless set; instruments the CPU path (run with WRAPPER_BCN_GPU=0).
WRAPPER_DIAG_TEX appended to a separate wrapper_tex_<appid>.txt; fold it into wrapper_diag_<appid>.txt (append) so a report is a single file to grab and share.
One switch: WRAPPER_DIAG=1 captures everything -- device blocks and the per-upload texture params/byte dumps -- into the single per-game diag file. No separate flag.
The texture dump only sat in the BCn transcode path, so anything that didn't reach it -- native passthrough formats, or textures that fail to create before upload -- was invisible. Add a copy-level log (WRAPPER_DIAG=1) at the entry of both CmdCopyBufferToImage and CmdCopyBufferToImage2 that records every copy to a tracked image: requested vs stored format, emulated flag, extent, mip, source stride, tiling, usage. Appends to the per-game diag file. This makes a missing texture visible by its absence (it never got copied) and catches non-BCn corruption too.
added 4 commits
July 5, 2026 10:06
# Conflicts: # README.rst
…n Xclipse
DXVK 2.5+ fails to initialize on Samsung Xclipse (RDNA) because the driver
exposes neither VK_KHR_maintenance5 nor maxPushConstantsSize >= 256.
Emulate VK_KHR_maintenance5 for D3D clients whose base driver lacks it
(self-limiting: Mali/Adreno expose it natively and are skipped):
- advertise the extension and fake the maintenance5 feature
- unlink VkPhysicalDeviceMaintenance5Features from the real CreateDevice pNext
- implement the new device entrypoints (CmdBindIndexBuffer2,
GetRenderingAreaGranularity, GetImageSubresourceLayout2,
GetDeviceImageSubresourceLayout) as prefer-native-else-translate, so they
forward to the driver where it has maintenance5 and translate where it doesn't
- fold VkBufferUsageFlags2CreateInfo back into the 32-bit usage in CreateBuffer
(DXVK 2.5+ specifies buffer usage via flags2 and leaves the old field 0)
Bump maxPushConstantsSize to 256 on Xclipse so DXVK 2.6+ stops skipping the
adapter ("does not support 256 of push data"); the underlying RDNA hardware
handles 256 and the driver does not enforce the reported limit at pipeline
creation.
Confirmed: DXVK 2.7.1 runs on Xclipse; no regression on Mali (native
maintenance5, emulation dormant).
WRAPPER_DIAG previously wrote only the wrapper's own capability report to the file; the vkd3d/DXVK/wine output that actually explains a failure (Heap too small, device-lost, format rejects, crashes) went to stdout/stderr/logcat separately, so a shared report was missing half the story. Now, for a D3D engine, the wrapper redirects the process's stdout+stderr into the diag file once (at first device creation), and routes its own WRAPPER_LOG lines there too when WRAPPER_DIAG is set. One per-game file now holds: the faked-extension decisions, the device-capability report, the texture dumps, and the vkd3d/DXVK error output -- everything needed to diagnose from a single shared file.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.