panDXVK v01

panDXVK v01

Summary

What this release targets. v01 is a compatibility build first, with the stability
fixes alongside it. The Sarek v1.14.1 sync carries the compatibility gain — three and a half
years of upstream renderer and state-handling fixes — and the BC→ASTC transcode exists so
textures display at all on Mali. Stability comes from the teardown and device-detachment
fixes and from the GPL library path disabling itself rather than crashing after repeated
link failures. The asynchronous pipeline compiler and the parallel transcode are where the
performance lives, and both are off by default: with no setting, the first draw that
needs a pipeline builds it inline. Read v01 as a correctness build that you can make faster,
not a fast one.

The first official release of panDXVK, and the first build not based on DXVK 1.10.3. The
code base is now synchronised with Sarek v1.14.1, which brings in roughly three and a half
years of upstream work alongside our panVK-specific pipeline compiler and parallel
BC→ASTC texture transcode. This build runs correctly on some panVK versions and not on
others — the difference is a driver capability, not a packaging fault. Read Notes before
installing, and check that your panVK build is one of the working ones.

Key Features

• Sarek v1.14.1 base — the translation layer now tracks Sarek rather than DXVK 1.10.3, gaining lock-free pipeline instance lookup, improved state handling and the upstream renderer fixes accumulated since 2022
• gplasync pipeline compiler — asynchronous pipeline compilation built on VK_EXT_graphics_pipeline_library, so a pipeline is built as libraries and linked instead of as one monolithic object; validated in back-to-back comparison against both upstream and Sarek's dyasync, and chosen for this release. Opt-in via dxvk.gplAsyncMode / PANDXVK_GPLASYNC — synchronous by default (see Configuration)
• Parallel BC→ASTC transcode — block-compressed textures are transcoded to ASTC across all cores at upload time; bit-exact against the reference decoder on all 13 format cases, and measured at 3.11–3.63× the throughput of the single-threaded path
• panVK-only targeting — Adreno devices are filtered out at instance creation, and the feature gate keys on Mali vendor ID 0x13b5, so desktop GPU assumptions never enter the path
• On-device telemetry — optional CSV timeline and report files for diagnosing stalls, off by default

Installation

1. Download merged.zip (manual DLL install) or pandxvk-v01.wcp (launcher install)
2. Replace the existing panDXVK DLLs with the ones from the archive
3. Set the environment variables described in Configuration if your panVK build reports BC support
4. Launch a game as usual

Configuration

Transcode

The transcode path is gated on a runtime capability check, so on some panVK builds the
environment variables below are not optional — without them the game will attempt to upload
raw BC textures the driver cannot sample, which is the usual cause of black or garbled
textures on those builds.

Variable	Values	Effect
PANDXVK_FORCE_TRANSCODE	1, or any value other than unset/empty/0	Forces BC→ASTC transcode even when the driver claims BC support. Required on builds where a BC wrapper layer fakes the feature. Adds CPU cost and ASTC loss — do not set it on builds that already transcode automatically.
PANDXVK_TELEMETRY	1	Enables the CSV timeline and report writer
PANDXVK_REPORT_DIR	path	Directory for telemetry output

⚠️ Do not pair the transcode with an updated wrapper BCN layer.

Charan's build (GunaCharanTeja/WinlatorMali, branch bionic-mali-1.0) carries an
updated wrapper BCN layer that is already verified working as intended — it performs the
same BC→usable-texture conversion in effect that panDXVK's transcode performs. Setting
PANDXVK_FORCE_TRANSCODE=1 alongside it puts both mechanisms on the same textures, and
they conflict.

Use one or the other, never both. If your setup's wrapper BCN layer is already
delivering correct textures, leave PANDXVK_FORCE_TRANSCODE unset. Set it only where a
wrapper advertises textureCompressionBC but its layer does not produce working
textures — in that case the flag is what activates BC→ASTC.

Pipeline compilation

Compilation is synchronous by default — the draw that needs a pipeline builds it inline
and pays the cost on that frame. Every option below is opt-in, and none of them is required
for a normal setup. Each can be given as a dxvk.conf key or as the environment variable
listed beside it.

dxvk.conf key	Environment variable	Default	Effect
dxvk.enableAsync	PANDXVK_ASYNC	False	Compiles pipelines on worker threads instead of stalling the draw
dxvk.enableGplAsync	PANDXVK_GPLASYNC	False	The same, using graphics pipeline libraries. Consulted only when gplAsyncMode is 0, in which case it is treated as mode 1
dxvk.gplAsyncMode	PANDXVK_GPLASYNC	0	0 off · 1 async · 2 async with graphics pipeline libraries. Any value ≥ 1 turns enableGplAsync on. The two live modes are described below the table.
dxvk.enableDyAsync	PANDXVK_DYASYNC	False	Dyasync: draws a fallback pipeline for the render pass while the real one compiles, instead of dropping the draw. The first draw of a pass still compiles inline, because no fallback exists yet. When set it takes the branch over PANDXVK_ASYNC
dxvk.numAsyncThreads	—	0	Worker threads. 0 picks half the CPU cores, clamped to 1–8
dxvk.asyncLog	PANDXVK_ASYNC_LOG	False	Logs compilation to the DXVK log, and warns on the first ten draws dropped for invalid pipeline state
—	PANDXVK_GPL_FASTLINK	unset	Experiments with the faster GPL link path

The two live modes. 0 does nothing. The values that actually change behaviour differ in
how a missing pipeline gets built:

• 1 — async, full compile. A draw that needs a pipeline state not seen before is queued
  to worker threads and compiled as one monolithic pipeline; the draw is skipped until it
  lands. Every pipeline compiled in the background is also written to the DXVK state cache, so
  the next launch precompiles them at startup and skips far fewer draws. dxvk.enableAsync on
  its own now writes that cache the same way, so its skipped draws no longer recur on every
  launch. With mode 2 off, mode 1 and dxvk.enableAsync therefore take the same path, and
  mode 1 is kept so existing configurations and the
  panDXVK: async=… gplasync=… startup line keep describing themselves as they did.
• 2 — async, build libraries and link. The same worker threads, and the same state-cache
  write, but instead of one monolithic pipeline the four stages are built separately and then
  linked: vertex input, pre-raster, fragment shader, fragment output. At startup it probes the
  driver for VK_EXT_graphics_pipeline_library, fast linking and independent interpolation
  decoration, and logs which of the three it found; if any is missing it quietly runs mode 1
  instead. If linking proves unreliable in practice it falls back to a full compile per
  pipeline and turns the library path off by itself after 8 such failures, saying so in
  the log — asynchronous compilation stays on, only the library path stops.

Only mode 2 can report library statistics, and it does so at shutdown: libraries created
and reused per stage, pipelines linked, fallbacks to full compile, library time, link time,
and whether the library path was still on when the device went away.

The startup line panDXVK: async=<0|1> gplasync=<0|1|2> reports what was actually picked
up, so the effective setting can be read from the log instead of assumed. Where mode 2
is requested the following line reports whether the driver offered the library feature,
fast linking and independent interpolation decoration, and which of the three it fell back
to.

Set everything the same way as any other DXVK variable — either in dxvk.conf, or as an
environment variable such as PANDXVK_FORCE_TRANSCODE=1 in the container's environment
before launch. Everything else is unchanged — normal setups work as they always have.

Changelog

• Added: Sarek v1.14.1 base — lock-free graphics pipeline instance lookup with instance, overflow and fallback maps, VK_EXT_graphics_pipeline_library plumbing, the DXVK_SAREK_STRICT diagnostic mode, and the upstream fixes and state handling landed since DXVK 1.10.3
• Added: parallel BC→ASTC transcode, bit-exact against the reference decoder on all 13 format cases and 3.11–3.63× faster than the single-threaded encoder
• Added: PANDXVK_FORCE_TRANSCODE, PANDXVK_TELEMETRY, PANDXVK_REPORT_DIR and PANDXVK_GPL_FASTLINK
• Changed: the pipeline compiler is panDXVK's gplasync implementation, kept ahead of Sarek's dyasync after back-to-back comparison
• Changed: the graphics pipeline keeps our GPL library keying and library cache alongside Sarek's lock-free instance maps, rather than either side alone
• Changed: D3D11 deferred and immediate contexts now report a full D3D11_MAPPED_SUBRESOURCE zero and reset the pending image slice when a map fails, instead of clearing only pData
• Changed: device filtering takes the 1.14 two-argument constructor, and the immediate and deferred contexts use the 1.14 Flush(contextId, flags) signature
• Added: PANDXVK_DYASYNC / dxvk.enableDyAsync, which draws a fallback pipeline for the render pass while the real one compiles instead of dropping the draw; off unless set, and it takes the branch over PANDXVK_ASYNC
• Changed: dxvk.enableAsync now writes the state cache after a successful compile, as the gplAsync modes and the synchronous path already did, so its skipped draws are precompiled next launch instead of recurring
• Removed: `dxvk.shaderCompilationMetho...

panDXVK v1.10.3-panVK.12 (CSV row-0 fix, transcode timing)

panDXVK v1.10.3-panVK.12

Summary

This release fixes the first row of timeline.csv, which reported lifetime counter totals instead of the window delta because the counter base was never seeded before the first sample. It also adds a duration to the initializer's BC→ASTC debug line, closing the gap that left a title which never calls UpdateSubresource1 with its transcode cost measured in bytes and never in time. Both changes are inert unless telemetry and debug logging are already enabled.

Key Features

• Row 0 of timeline.csv now reports a true window delta — the first on-device sample recorded 142 % GPU idle over a 60-second window, which is impossible and is corrected here
• panDXVK: BC→ASTC initializer upload now ends with <ms>ms, so the initializer path every CreateTexture title uses finally reports how long the render thread spent encoding

Installation

1. Download merged.zip (manual DLL install) or pandxvk-1.10.3.wcp (launcher install)
2. Replace the existing panDXVK DLLs with the ones from the archive
3. Launch a game as usual

Configuration

unchanged

Changelog

• Added: per-upload duration on the panDXVK: BC→ASTC initializer upload debug line, gated on Logger::logLevel() so release builds take no clock read
• Changed: the initializer metric now ends ...B <ms>ms instead of ...B
• Fixed: row 0 of timeline.csv diffed its ten counters against zero, reporting totals since device creation rather than the window delta — observed as 85,496,921 µs of GPU idle inside a 60,098,000 µs window
• Removed: none

Credits

• doitsujin/dxvk — upstream DXVK
• pythonlover02/dxvk-sarek — Sarek fork
• Wonderkast — BC7/ASTC technical review, lead of panVK for Mali G720
• leegao/bcn_layer — BCN wrapper layer reference
• richgel999/bc7enc — BC7 differential oracle
• iOrange/bcdec — BC6H differential oracle (MIT)
• isygold/panDXVK-logs — community log repo

Upstream DXVK Reference

• doitsujin/dxvk — based on DXVK v1.10.3 (upstream current: v3.1)

panDXVK v1.10.3-panVK.11 (Telemetry fixed, CSV timeline)

panDXVK v1.10.3-panVK.11

Summary

This release fixes a telemetry bug that silenced the module from its second launch onward, so session reports and crash detection now work on repeated runs. It also adds timeline.csv, a periodic performance dump written beside report.json so that samples already on disk survive a crash. Both changes are gated behind PANDXVK_TELEMETRY and alter nothing for a tester who does not set it.

Key Features

• timeline.csv: one row every 60 seconds carrying identity, windowed FPS/frame-time and ten stat-counter deltas, appended and flushed per row so a crash cannot lose it
• Telemetry directory creation is now best-effort; the crash-marker probe decides whether the directory is usable, which restores crash detection on every run after the first

Installation

1. Download merged.zip (manual DLL install) or pandxvk-1.10.3.wcp (launcher install)
2. Replace the existing panDXVK DLLs with the ones from the archive
3. Launch a game as usual

Configuration

unchanged

Changelog

• Added: timeline.csv — a 60-second CSV timeline of FPS, frame time, draw/submit counts and GpuIdleTicks / GpuSyncTicks, written from onPresent() when PANDXVK_TELEMETRY is set
• Changed: telemetry directory creation is best-effort rather than fatal, with the existing marker-file open retained as the usability gate
• Fixed: telemetry disabled itself from the second run onward, because CreateDirectoryW fails when the directory already exists — this also made crash detection unreachable after any run that created the folder
• Removed: the panDXVK telemetry: cannot create diagnostic, superseded by the path-naming cannot write message

Credits

• doitsujin/dxvk — upstream DXVK
• pythonlover02/dxvk-sarek — Sarek fork
• Wonderkast — BC7/ASTC technical review, lead of panVK for Mali G720
• leegao/bcn_layer — BCN wrapper layer reference
• richgel999/bc7enc — BC7 differential oracle
• iOrange/bcdec — BC6H differential oracle (MIT)
• isygold/panDXVK-logs — community log repo

Upstream DXVK Reference

• doitsujin/dxvk — based on DXVK v1.10.3 (upstream current: v3.1)

panDXVK v1.10.3-panVK.10 (Telemetry)

panDXVK v1.10.3-panVK.10

Summary

v10 adds session reports and crash detection — the build can now write down what it saw during a run, including whether the run ended badly, so a report can arrive with the data instead of a description of the data. Everything it writes is behind a single switch that is off by default: with PANDXVK_TELEMETRY unset, nothing is created, nothing is logged, and the release path is unchanged from v9-1.

This is an instrumentation build, not a rendering change. If it looks different from v9-1 on the same scene and the same flags, that is a regression and we want the log.

Key Features

• PANDXVK_TELEMETRY switch — one environment variable, default off. Unset, it costs a single boolean test per call and touches no files.
• report.json — written to a pandxvk-reports/ subfolder on a clean exit. Carries build identity, device and driver, frame statistics with a frametime histogram, bind totals, and the submission section. Kept in a subfolder so top-level logs stay visible after a crash.
• Crash detection — a .crash_marker is created at session start and removed on a clean exit. A leftover marker means the run did not finish, and the build writes an issue.md describing it.
• attachments.txt — on a clean exit, a manifest listing the log files from DXVK_LOG_PATH, so a report can name its files without shipping a copy of a file that is still being written.
• Bind totals in the report — total, distinct and skippable accumulated across the run and carried in report.json, alongside the per-command-list dxvk bind stats: line from v9-1.
• Submission and HAAE replay — counts submits, draws per submit, and how often each of the three HAAE tiers (50 / 100 / 150 draws) would have fired. Observational only — it records what would have happened and changes nothing about the submit.

Installation

Option A — WCP (recommended):

1. Download pandxvk-1.10.3.wcp from the assets below.
2. In Winlator/Bannerlator, go to Container Settings → Content.
3. Tap Install and select the downloaded file.
4. Launch your game.

Option B — Manual DLL replacement:

1. Download merged.zip (x64 + x32 DLLs) from the assets below.
2. Extract the archive.
3. Replace d3d11.dll, dxgi.dll, d3d10.dll, d3d10_1.dll, d3d9.dll with the ones matching your container's architecture:
   • 64-bit folder (system32)
   • 32-bit folder (syswow64)
4. Launch your game.

Configuration

New, and required to get any report:

PANDXVK_TELEMETRY = 1

Also required if you want bind totals in the report:

DXVK_LOG_LEVEL = debug

Bind totals are accumulated from the same per-command-list statistics the v9-1 counter uses, so they follow that counter's rule: without DXVK_LOG_LEVEL=debug the counts are never taken. Setting only PANDXVK_TELEMETRY still produces a report — it just has no bind section filled in.

Everything else is unchanged from v9-1.

Changelog

Changes since v1.10.3-panVK.9-1:

• Added:
  • PANDXVK_TELEMETRY environment variable. Default is off; anything other than the string 0 enables it.
  • pandxvk-reports/report.json, written on clean exit — build, device, driver, frames, histogram, bind totals, submission section.
  • .crash_marker created at session start and removed on clean exit; a leftover marker triggers an issue.md.
  • attachments.txt manifest of log files on clean exit.
  • Bind totals (total / distinct / skippable) accumulated process-wide and carried in report.json.
  • Observational HAAE tier replay — counts how often 50 / 100 / 150-draw tiers would have fired. Never modifies a submit.
• Changed:
  • The per-command-list dxvk bind stats: line from v9-1 is unchanged; its numbers now additionally feed report.json.
• Fixed:
  • Nothing user-visible in this build. The instrumentation itself has not yet been run on a device.

Notes

• How to tell this build apart. The version line reads 1.10.3.v10 (694fefac). That identifier is what to paste into a report.
• Nothing happens unless you ask for it. With PANDXVK_TELEMETRY unset there is no pandxvk-reports/ folder, no marker file, and no extra log line. If you see one, that is a bug.
• What we want back, first. One run of about two minutes of gameplay with PANDXVK_TELEMETRY = 1 and DXVK_LOG_LEVEL = debug, then the pandxvk-reports/ folder plus d3d11.log and dxgi.log.
• What we are checking. That report.json is well-formed and contains the sections listed above; that a crash leaves a .crash_marker behind; and that a run with the switch unset creates nothing new.
• The HAAE section is a measurement, not a feature. It reads draw counts and prints how often a tier would have fired. It does not pace anything. Any real pacing change will be proposed separately, after we have numbers.
• The bind-skip idea is closed for now. The v9-1 measurement put d3d11 at 1.46% skippable and the nine small meta paths at 0.06%, below the protocol's own threshold. The counter stays so a future run can contradict it.
• For now do not test with the PanVK driver — use the blob driver.
• Enable wine logs in your Winlator version's settings so a wine_debug.log file is generated — d3d11.log alone cannot explain crashes.
• D3D11 only. The D3D9 path is untouched.
• Known limitation: ASTC textures are not decoded on readback (Map of a transcoded texture returns ASTC bytes), so CPU-side readback of BC-origin texture data is wrong on force-on runs.

Credits

• doitsujin/dxvk — upstream DXVK
• pythonlover02/dxvk-sarek — Sarek fork
• Wonderkast — BC7/ASTC technical review, lead of panVK for Mali G720
• leegao/bcn_layer — BCN wrapper layer reference
• richgel999/bc7enc — BC7 differential oracle
• iOrange/bcdec — BC6H differential oracle (MIT)
• isygold/panDXVK-logs — community log repo

Upstream DXVK Reference

• doitsujin/dxvk — based on DXVK v1.10.3 (upstream current: v3.1)

panDXVK v1.10.3-panVK.9-1 (Measurement)

panDXVK v1.10.3-panVK.9-1

Summary

This is a measurement build, not a fix. Nothing is broken in v9.

It does two things:

1. It fixes the texture colour bug (the ASTC encoder fix, 5aa58c3c).
2. It counts pipeline re-binds, so we can decide whether a bind-skip is worth writing for Mali.

The counter only works if you set DXVK_LOG_LEVEL=debug. Without it, nothing is counted.

Key Features

• Texture colour fix — ASTC blocks now fit colours along the block's real colour axis instead of the bounding-box diagonal. Saturated red and blue blocks stop turning the wrong hue.
• Bind counter — writes dxvk bind stats: total=… distinct=… skippable=… into d3d11.log, once per command list. A high skippable means a bind-skip would help; a low one means it would not.
• The counter costs nothing in a normal run — it is gated on the log level, not on NDEBUG, so an ordinary run at the default level never touches it.

Installation

Option A — WCP (recommended):

1. Download pandxvk-1.10.3.wcp from the assets below.
2. In Winlator/Bannerlator, go to Container Settings → Content.
3. Tap Install and select the downloaded file.
4. Launch your game.

Option B — Manual DLL replacement:

1. Download merged.zip (x64 + x32 DLLs) from the assets below.
2. Extract the archive.
3. Replace d3d11.dll, dxgi.dll, d3d10.dll, d3d10_1.dll, d3d9.dll with the ones matching your container's architecture:
   • 64-bit folder (system32)
   • 32-bit folder (syswow64)
4. Launch your game.

Configuration

To use the counter you must set:

DXVK_LOG_LEVEL=debug

Everything else is unchanged from v9.

Changelog

• Added:
  • dxvk bind stats: total=… distinct=… skippable=… in d3d11.log, one line per command list, gated at runtime on DXVK_LOG_LEVEL=debug.
• Fixed:
  • ASTC colours were rewritten on some blocks. The two endpoints were taken from the block's bounding-box diagonal, which is the right axis only when a block's colours happen to lie on it. On random BC1 blocks, 74.5% were off by 32 or more on their worst texel, and on saturated anti-correlated content (red to green) the mean worst-channel error was 100.9 out of 255. The encoder now builds two candidates — the old one and one fitted to the block's principal colour axis — and keeps whichever has the lower worst texel. A block that picks the old path emits byte-identical output to before, so no block can get worse than it was.
• Changed:
  • Internal only: CI now packages the build from the commit you asked for, instead of whatever build happened to run last. No effect on the DLLs.

Notes

• This is a measurement build. Please do not use it for general play. We need one run and the log.
• You must set DXVK_LOG_LEVEL=debug. If you do not, the counter stays off and the log will have no stats line. This is the most common way this test fails.
• How to tell this build apart. The version line reads 1.10.3.v9 (698b9086). That is correct — it shares the v9 release number on purpose. (698b9086) is the identifier. The shipped v9 reads 1.10.3.v9 (0db4aa2b).
• What we want back. The whole log folder from one run of about two minutes of gameplay, including d3d11.log and dxgi.log.
• How we read the result.
  • skippable close to total — we write the bind-skip.
  • skippable near zero — we drop the idea. Either answer is a good outcome.
  • No stats line at all — the log level did not reach the game; send the log anyway and say so.
• All other v9 guidance still applies (force flag, wine logs, blob driver, WRAPPER_NO_PATCH_OPCONSTCOMP).
• For now do not test with the PanVK driver — use the blob driver.
• Enable wine logs in your Winlator version's settings so a wine_debug.log file is generated — d3d11.log alone cannot explain crashes.
• D3D11 only. The D3D9 path is untouched.
• Known limitation: ASTC textures are not decoded on readback (Map of a transcoded texture returns ASTC bytes), so CPU-side readback of BC-origin textures is wrong on force-on runs.

Credits

• doitsujin/dxvk — upstream DXVK
• pythonlover02/dxvk-sarek — Sarek fork
• Wonderkast — BC7/ASTC technical review, lead of panVK for Mali G720
• leegao/bcn_layer — BCN wrapper layer reference
• richgel999/bc7enc — BC7 differential oracle
• iOrange/bcdec — BC6H differential oracle (MIT)
• isygold/panDXVK-logs — community log repo

Upstream DXVK Reference

• doitsujin/dxvk — based on DXVK v1.10.3 (upstream current: v3.1)

panDXVK v1.10.3-panVK.9 (Experimental)

panDXVK v1.10.3-panVK.9

Summary

v1.10.3-panVK.9 makes panDXVK self-identifying and tightens two correctness gates. The startup log and the HUD now report the panDXVK release and the exact commit instead of upstream's bare DXVK 1.10.3, so a tester screenshot or a pasted log names the build it came from without anyone having to guess. It also narrows isBcFormat to the BC ranges that actually exist in DXGI, after proving the old range admitted nine non-BC formats — including the standard back-buffer format. Finally it puts the per-upload transcode timing and the ASTC and BC7 block statistics into the release build — they were previously unreachable or compiled out — so the performance work that follows is measured rather than assumed.

Key Features

• panDXVK release + commit in HUD and log — panDXVK 1.10.3.v9 (0db4aa2b) in the HUD, panDXVK: 1.10.3.v9 (0db4aa2b) in the log, with the raw DXVK: v1.10.3-panVK.9 describe detail retained on the next line.
• Release strings that survive every git shape — the release half is parsed from git describe and keeps only the leading digits after panVK., so an on-tag build, a between-tag build and a dirty build all report a clean 1.10.3.v9.
• isBcFormat(DXGI_FORMAT) restricted to the real BC ranges — (BC1_TYPELESS..BC5_SNORM) || (BC6H_TYPELESS..BC7_UNORM_SRGB) instead of one 70..99 run.
• rmchk ASTC spec gate in CI — an independent decoder written from the spec cross-checks block-mode decoding against both the spec text and basisu on every build, replacing a gate that validated itself.
• Gate inputs stated by the log — panDXVK: BC→ASTC gate: BC=… ASTC_LDR=… force=… -> transcode ENABLED/disabled printed once at device creation, so a log says why the transcode is on instead of leaving it to be reverse-engineered.
• Release builds are NDEBUG, but stay measurable — diagnostics that would distort performance are compiled out, while everything a tester log or a benchmark depends on is gated at runtime on DXVK_LOG_LEVEL=debug instead: the four transcode markers, the per-upload BC→ASTC transcode …ms timing, and the ASTC and BC7 block statistics.

Installation

Option A — WCP (recommended):

1. Download pandxvk-1.10.3.wcp from the assets below.
2. In Winlator/Bannerlator, go to Container Settings → Content.
3. Tap Install and select the downloaded file.
4. Launch your game.

Option B — Manual DLL replacement:

1. Download merged.zip (x64 + x32 DLLs) from the assets below.
2. Extract the archive.
3. Replace d3d11.dll, dxgi.dll, d3d10.dll, d3d10_1.dll, d3d9.dll with the ones matching your container's architecture:
   • 64-bit folder (system32)
   • 32-bit folder (syswow64)
4. Launch your game.

Configuration

unchanged

Changelog

• Added:
  • panDXVK <release> (<commit>) as the first line of the startup log and as the HUD version line, plus a README ## Version String section documenting the format.
  • PAN_DXVK_COMMIT, fed by a second vcs_tag, because git describe emits no hash when a build sits exactly on a release tag.
  • rmchk promoted to CI as tests/host/rmchk.cpp + job gate-astc-spec; both cross-builds now depend on it.
  • The BC→ASTC gate: INFO line in DxvkAdapter::createDevice.
  • Permanent CI diagnostics: a Version source step (.git presence, git on PATH, HEAD, describe, tags at HEAD) and a dump of the generated version.h / pandxvk_version.h after ninja install.
  • Tester findings and the wrapper_no_patch guidance in the README.
  • The per-upload panDXVK: BC→ASTC transcode …ms timing, the [panDXVK ASTC encode] total=… uniform=… direct=… block statistics and the [panDXVK] BC7 decode stats breakdown are all emitted from release builds, gated at runtime on DXVK_LOG_LEVEL=debug. The two statistics dumps previously never ran in any build: the ASTC one was called only from a function with no callers, and the BC7 one was compiled out together with its own counters.
• Changed:
  • Release builds now pass -Db_ndebug=true.
  • git describe now uses --tags, so lightweight release tags are described instead of being rejected.
  • Container CI installs git before checkout and marks the workspace safe.directory, so the checkout is a real clone git accepts.
  • README RAM figure corrected to 5–8% (tester-measured, twice) and evidence not deliberately pursued is marked as such.
• Fixed:
  • isBcFormat accepted nine non-BC DXGI formats, from B8G8R8A8_TYPELESS through B8G8R8X8_UNORM_SRGB — including B8G8R8A8_UNORM, the usual back-buffer format. Old-vs-new acceptance diff: 30 → 21, changed set exactly 85..93, no BC format lost. The VkFormat overload was already correct and is untouched.
  • HUD and log showed upstream's DXVK 1.10.3, with no panDXVK release suffix and no commit. Three layered causes were each proven from a CI log: git describe without --tags, a tarball checkout with no .git, and git's dubious ownership rejection in the container — all three silently fall back to the project version.
  • A dirty-build marker leaked into the release number. build.yml ran chmod +x on a file tracked as 100644, which made git describe --dirty=+ append +; with no -N-g tail to cut on a tagged build, that reached the shipped string as 1.10.3.v9+.
  • The release build had no way to measure itself. The per-upload transcode timer and the ASTC block counters sat inside #ifndef NDEBUG, so turning -Db_ndebug=true on compiled them out completely — the one number that says what BC→ASTC transcode costs was unavailable in the only build anyone can benchmark. They are now gated at runtime on the log level instead, the same treatment the four transcode markers already had.
  • The statistics dumps still never printed. The ASTC dump's only call site was inside encodeAstcImage4x4, which has no production caller at all — the linker dropped that function and its string literal with it, so [panDXVK ASTC encode] was absent even from a debug build. The BC7 dump was #ifndef NDEBUG, as were its counters, so it printed nothing and would have read zeros. Both now run at the end of transcodeBcBlocksToAstc, the single function the DXGI path and the VkFormat overload both reach (the VkFormat overload skips transcodeBcToAstc), gated on the log level.
• Removed:
  • baseOffBlocks and maxWeightClamp from [panDXVK ASTC encode]. Neither can ever be non-zero: this encoder only ever writes CEM 12, so no base+offset path exists to count, and min/max are taken over the same 16 pixels, which puts t = dot(d, range)/|range|² in [0,1] by construction and makes both weight-clamp guards unreachable. A field that provably never moves reads as a measurement when it is a constant. The dump is now total=… uniform=… direct=…, and every number in it can change.

Notes

• This release changes identity and correctness, not rendering. v9 should look exactly like v8 did. The texture fix shipped in v8 (0x241); nothing here alters the ASTC layout. If v9 renders differently from v8 on the same scene and the same flags, that is a regression and we want a d3d11.log.
• How to name your build. The first line of the log is now panDXVK: 1.10.3.v9 (<commit>) and the HUD shows panDXVK 1.10.3.v9 (<commit>). Quote that line in any report — it identifies the exact build without anyone having to infer it from a file date. The line beneath it, DXVK: v1.10.3-panVK.9, is the raw git describe and is kept for detail.
• Reading d3d11.log — what proves the transcode actually ran. The authoritative markers are the one-time panDXVK: BC->ASTC remap VkImage… line plus panDXVK: SRV BC→ASTC / panDXVK: RTV BC→ASTC when views are created. The panDXVK: BC→ASTC transcode …ms timings and the PANDXVK_FORCE_TRANSCODE=1 notice appear only on the UpdateSubresource path; titles that upload initial data through the D3D11 initializer legitimately show zero of both — that is not a gate failure. Success also means no d3d11+0x60731 backtrace. The gate is off only when there are zero remap lines, which prints panDXVK: BC→ASTC transcode unavailable once near the top of the log.
• The gate now states itself. Near the top of the log, panDXVK: BC→ASTC gate: BC=… ASTC_LDR=… force=… -> transcode ENABLED/disabled gives the inputs directly. Include it when reporting.
• Measuring v9. The statistics are now in release builds — but they still need DXVK_LOG_LEVEL = debug. Each panDXVK: BC→ASTC transcode <W>x<H> DXGI_FORMAT=<n> sub=<n> <ms>ms line is one upload in milliseconds; sum them over a frame to get what the transcode costs on your device. [panDXVK ASTC encode] total=… uniform=… direct=… prints every 10000th transcode and shows how many blocks took the cheap uniform path rather than the full endpoint fit. [panDXVK] BC7 decode stats prints every 1000th BC7 transcode with a per-mode breakdown and an unhandled: count if any block mode the decoder does not implement shows up. With the log level below debug neither the clock nor the log strings are touched, so an ordinary run pays only a few counter increments.
• Tester configuration (unchanged from v5). Set these where your launcher passes env to the game: PANDXVK_FORCE_TRANSCODE = 1, DXVK_LOG_LEVEL = debug, DXVK_LOG_PATH = /sdcard/Download. Both the force flag and the log level must reach the game — level alone silences all transcode diagnostics. All of these need a game restart to take effect.
• Set WRAPPER_NO_PATCH_OPCONSTCOMP = 0 before testing. If you get a crash or black screen, revert it to 1. This is the name the wrapper actually reads (wrapper_device.c: getenv("WRAPPER_NO_PATCH_OPCONSTCOMP")), it is what Winlator Mali sets to 1 by default, and the plain WRAPPER_NO_PATCH spelling is read by nothing — setting it changes nothing.
• **For now don't test with the PanVK driver — use the blob driv...

panDXVK v1.10.3-panVK.8 (Experimental)

panDXVK v1.10.3-panVK.8

Summary

v1.10.3-panVK.8 fixes the block-mode header word that made panVK.7 render worse than panVK.6. The 3-bit weight-range field R is defined by C.2.6 as "a 3 bit value" whose bits are R0 (least significant), R1 and R2 (most significant), but it was being assembled in the block-mode column order {R0, R2, R1} — which swaps R2/R1 and therefore reads the wrong range: 0x242 means 0..15 (64 weight bits), not the intended 0..9 (54). Mali consequently read eight weight bits out of the endpoint data and remaining_bits fell to 47, which also dragged the endpoints off the 7-bit range — that is the missing/corrupt/partial texture reported on panVK.7. The corrected order selects block mode 0x241, the only non-dual-plane mode giving a 4×4 grid with range 0..9, so every other layout constant is unchanged.

Key Features

• Block mode 0x241: the only non-dual-plane block mode encoding a 4×4 weight grid with weight range 0..9 — one quint plus one LSB per weight, 10 levels
• R assembled as R2·4 + R1·2 + R0 per C.2.6, cross-checked against basisu's shipped UASTC block-mode/range pairings: 6/6 correct, versus 2/6 for the old column-order read
• Weight stream, endpoint range and bit budget unchanged: 54 weight bits stored downward from bit 127, 7-bit endpoints at bits [17:72], exactly one padding bit at bit 73
• An independent decoder written from astc_spec.txt agrees with the product encoder bit-for-bit (0 mismatches in 4098 blocks)

Installation

Option A — WCP (recommended):

1. Download pandxvk-1.10.3.wcp from the assets below.
2. In Winlator/Bannerlator, go to Container Settings → Content.
3. Tap Install and select the downloaded file.
4. Launch your game.

Option B — Manual DLL replacement:

1. Download merged.zip (x64 + x32 DLLs) from the assets below.
2. Extract the archive.
3. Replace d3d11.dll, dxgi.dll, d3d10.dll, d3d10_1.dll, d3d9.dll with the ones matching your container's architecture:
   • 64-bit folder (system32)
   • 32-bit folder (syswow64)
4. Launch your game.

Configuration

unchanged

Changelog

• Added:
  • None.
• Changed:
  • Block mode 0x242 -> 0x241. Same 4×4 grid, same intended 0..9 weight range, correct header word.
  • The round-trip gate's decodeBlockMode() now assembles R as R2 R1 R0. It previously shared the encoder's misreading, which is why every gate stayed green while the mode was wrong.
  • Header comment in util_astc_encode.h rewritten to derive the constant from C.2.6/C.2.7 the way the spec states it.
• Fixed:
  • Corrupted, missing and partially shown textures on panVK.7. Under 0x242 a conforming decoder reads 64 weight bits where 54 were written, taking the last eight from the endpoint region, and remaining_bits = 47 selects a trit/quint endpoint range instead of 7-bit — so both the weights and the colours came out wrong. Corrected by reading R in value order; the block mode that actually means 4×4 + 0..9 is 0x241.
  • The hazy, washed-out detail panVK.6 was shipped to fix. 0x51 decodes to range 0..2 (1 trit, 26 weight bits), not the intended 0..4 — the intended mode is 0x52. Endpoints were unaffected (8-bit still fits in remaining_bits = 85), which is why panVK.6 looked recognisable but soft, and why the harness disagreed with the device.
• Removed:
  • None.

Notes

• Reading d3d11.log — what proves the transcode actually ran. The authoritative markers are the one-time panDXVK: BC->ASTC remap VkImage… line plus panDXVK: SRV BC→ASTC / panDXVK: RTV BC→ASTC when views are created. The panDXVK: BC→ASTC transcode …us timings and the PANDXVK_FORCE_TRANSCODE=1 notice appear only on the UpdateSubresource path; titles that upload initial data through the D3D11 initializer legitimately show zero of both — that is not a gate failure. Success also means no d3d11+0x60731 backtrace. The gate is off only when there are zero remap lines, which prints panDXVK: BC->ASTC transcode unavailable once near the top of the log.
• Tester configuration (unchanged from v5). Set these where your launcher passes env to the game: PANDXVK_FORCE_TRANSCODE = 1, DXVK_LOG_LEVEL = debug, DXVK_LOG_PATH = /sdcard/Download. Both the force flag and the log level must reach the game — level alone silences all transcode diagnostics. All of these need a game restart to take effect.
• Set WRAPPER_NO_PATCH = 0 before testing. If you get a crash or black screen, revert it to 1.
• For now don't test with the PanVK driver — use the blob driver.
• Run a force-off control (PANDXVK_FORCE_TRANSCODE = 0) alongside. It should produce zero remap lines and is the baseline for any crash comparison.
• Zero remap lines means the driver reports textureCompressionASTC_LDR = 0, so the gate is correctly disabled — a driver-report problem, not a transcode problem. Report it with the Device properties: block.
• Enable wine logs in your Winlator version's settings so a wine_debug.log file is generated — d3d11.log alone cannot explain crashes.
• What to look for in v8. panVK.7 shipped the wrong header word and was worse than panVK.6: textures missing, heavily corrupted, or present on one part of the screen and absent on another. This release corrects that word. The expected result is no corruption whatsoever — everything panVK.6 showed, plus the sharper 10-level detail panVK.7 promised. A force-on v6/v8 side-by-side on the same Silksong scene is the decisive test: v8 should match v6 for completeness and beat it for sharpness. If any texture is still missing or partially drawn on v8, the diagnosis is wrong and we need a fresh d3d11.log plus the Device properties: block.
• D3D11 only. The D3D9 path is untouched, and d3d9 still forces textureCompressionBC at device creation — not covered by this fix.
• Known limitation: ASTC textures are not decoded on readback (Map of a transcoded texture returns ASTC bytes), so CPU-side readback of BC-origin textures is wrong on force-on runs.

Credits

• doitsujin/dxvk — upstream DXVK
• pythonlover02/dxvk-sarek — Sarek fork
• Wonderkast — BC7/ASTC technical review, lead of panVK for Mali G720
• leegao/bcn_layer — BCN wrapper layer reference
• richgel999/bc7enc — BC7 differential oracle
• iOrange/bcdec — BC6H differential oracle (MIT)
• isygold/panDXVK-logs — community log repo

[Testers] Thank you:

• Gustave (Mali-G52) — Nine Sols, Silksong, Sugary Spire, GTA V logs plus the wine logs that named the crash. The most consistent logger we've had — every diagnosis this release traces back to your files. Genuinely appreciated.
• Us5rman (Mali-G615) — AIO/FPS baselines, FF7, MOTORSLICE, NFS reports that mapped the early territory.
• @UriYuanKerr69 (Mali-G52) — Cult of PiN (v2 + v3 builds with screenshots), Dead Cells, Streets of Rogue, Loopler reports.
• LORD (Mali-G720) — Silksong + long-session NFS13 logs on new silicon.
• Loyd (Mali-G615) — DMC5 + GTA V runs.
• DUCKTEN (Mali-G615) — NFS + AC3SP sessions.

Upstream DXVK Reference

• doitsujin/dxvk — based on DXVK v1.10.3 (upstream current: v3.1)

panDXVK v1.10.3-panVK.7 (Experimental)

panDXVK v1.10.3-panVK.7

Summary

v1.10.3-panVK.7 doubles the ASTC 4x4 encoder's weight resolution, moving the block from mode 0x51 (weight range 0..4, 5 levels) to mode 0x242 (weight range 0..9, 10 levels) and paying for it with one endpoint bit per value (8 bits total). Against the clean ground-truth frame and the reference decoder this measures 37.82 -> 39.92 dB, a +2.10 dB improvement over 2820 blocks with zero decode failures, and the encoder now emits blocks bit-identical to the independently written candidate encoder (0 mismatches in 4098 blocks). The block remains fully spec-conformant: 54-bit weight stream stored downward from bit 127, 7-bit endpoints restored by the spec's bit replication, exactly one padding bit.

Key Features

• Block mode 0x242: a legal 4x4 weight grid selecting weight range 0..9 — one quint plus one LSB per weight, 10 levels instead of 5
• Weight stream ISE-packed to C.2.12's group layout for n=1 (five 10-bit groups + a 4-bit tail = 54 bits) and stored downward from block bit 127 per C.2.16
• Endpoints stored as 7-bit values (8 x 7 = 56 bits); remaining_bits = 128 - 17 - 54 = 57, leaving exactly one padding bit at bit 73
• Endpoint restoration by C.2.13 simple bit replication from the MSB, keeping the round trip within one LSB for every input value
• Weight quantizer targets the unquantized 0..64 scale rather than the index, because Table C.2.17's index order is not monotonic (index 1 -> 64, index 2 -> 7)

Installation

Option A — WCP (recommended):

1. Download pandxvk-1.10.3.wcp from the assets below.
2. In Winlator/Bannerlator, go to Container Settings → Content.
3. Tap Install and select the downloaded file.
4. Launch your game.

Option B — Manual DLL replacement:

1. Download merged.zip (x64 + x32 DLLs) from the assets below.
2. Extract the archive.
3. Replace d3d11.dll, dxgi.dll, d3d10.dll, d3d10_1.dll, d3d9.dll with the ones matching your container's architecture:
   • 64-bit folder (system32)
   • 32-bit folder (syswow64)
4. Launch your game.

Configuration

unchanged

Changelog

• Added:
  • unquantWeightQuint1() — Table C.2.17 for the 0..9 range, producing {0,7,14,21,28,36,43,50,57,64} on the 0..64 weight scale
  • quantizeWeightQuint1() — quantizes by nearest unquantized level with ties resolving to the lowest index, so it agrees with the candidate encoder bit for bit
  • packWeightQuint1Bits() — C.2.12 quint+1LSB packing: five full 10-bit groups plus a 4-bit trailing group
  • Two static_asserts pinning the one-bit gap between the endpoint and weight streams, and that remaining_bits can hold the endpoint stream
• Changed:
  • Block mode 0x51 -> 0x242, raising the declared weight range from 0..4 to 0..9 (5 -> 10 levels)
  • Weight stream 38 -> 54 bits, now written at block bit 74 instead of 90
  • Endpoints 8 -> 7 bits: stored as value >> 1 and restored by bit replication, because remaining_bits drops from 73 to 57
  • writeBlockHeader() and writeEndpoints() write the new layout; reverseBits()/writeBits() comments updated to 74/54
• Fixed:
  • Texture reconstruction quality. The 5-level weight range was the largest single source of error in the transcode: on the clean ground-truth frame the encoder measured 37.82 dB, and the weight range alone accounted for +1.78 dB of the +4.5 dB available headroom. Moving to 10 levels with 7-bit endpoints recovers +2.10 dB (37.82 -> 39.92 dB) over 2820 blocks with zero decode failures. Visible as hazy, washed-out detail on 2D artwork.
• Removed:
  • quantizeWeightTo() and quantizeWeight() — no remaining callers, and their linear mapping is wrong for the non-monotonic 0..9 range

Notes

• Reading d3d11.log — what proves the transcode actually ran. The authoritative markers are the one-time panDXVK: BC->ASTC remap VkImage… line plus panDXVK: SRV BC→ASTC / panDXVK: RTV BC→ASTC when views are created. The panDXVK: BC→ASTC transcode …us timings and the PANDXVK_FORCE_TRANSCODE=1 notice appear only on the UpdateSubresource path; titles that upload initial data through the D3D11 initializer legitimately show zero of both — that is not a gate failure. Success also means no d3d11+0x60731 backtrace. The gate is off only when there are zero remap lines, which prints panDXVK: BC->ASTC transcode unavailable once near the top of the log.
• Tester configuration (unchanged from v5). Set these where your launcher passes env to the game: PANDXVK_FORCE_TRANSCODE = 1, DXVK_LOG_LEVEL = debug, DXVK_LOG_PATH = /sdcard/Download. Both the force flag and the log level must reach the game — level alone silences all transcode diagnostics. All of these need a game restart to take effect.
• Set WRAPPER_NO_PATCH = 0 before testing. If you get a crash or black screen, revert it to 1.
• For now don't test with the PanVK driver — use the blob driver.
• Run a force-off control (PANDXVK_FORCE_TRANSCODE = 0) alongside. It should produce zero remap lines and is the baseline for any crash comparison.
• Zero remap lines means the driver reports textureCompressionASTC_LDR = 0, so the gate is correctly disabled — a driver-report problem, not a transcode problem. Report it with the Device properties: block.
• Enable wine logs in your Winlator version's settings so a wine_debug.log file is generated — d3d11.log alone cannot explain crashes.
• What to look for in v7. This release changes only the ASTC block's weight range (5 levels → 10) and endpoint precision (8-bit → 7-bit). Hazy, washed-out fine detail and 2D artwork should sharpen; flat menus and splash screens should look essentially the same. The failure mode to watch for is the opposite: if the Mali decoder rejects the new block mode you would see garbled or wrongly-coloured textures across the board, not a subtle haze — that regression would be new in v7 and absent in v6, so a force-on v6/v7 side-by-side on the same scene is the decisive comparison.
• D3D11 only. The D3D9 path is untouched, and d3d9 still forces textureCompressionBC at device creation — not covered by this fix.
• Known limitation: ASTC textures are not decoded on readback (Map of a transcoded texture returns ASTC bytes), so CPU-side readback of BC-origin textures is wrong on force-on runs.

Credits

• doitsujin/dxvk — upstream DXVK
• pythonlover02/dxvk-sarek — Sarek fork
• Wonderkast — BC7/ASTC technical review, lead of panVK for Mali G720
• leegao/bcn_layer — BCN wrapper layer reference
• richgel999/bc7enc — BC7 differential oracle
• iOrange/bcdec — BC6H differential oracle (MIT)
• isygold/panDXVK-logs — community log repo

[Testers] Thank you:

• Gustave (Mali-G52) — Nine Sols, Silksong, Sugary Spire, GTA V logs plus the wine logs that named the crash. The most consistent logger we've had — every diagnosis this release traces back to your files. Genuinely appreciated.
• Us5rman (Mali-G615) — AIO/FPS baselines, FF7, MOTORSLICE, NFS reports that mapped the early territory.
• @UriYuanKerr69 (Mali-G52) — Cult of PiN (v2 + v3 builds with screenshots), Dead Cells, Streets of Rogue, Loopler reports.
• LORD (Mali-G720) — Silksong + long-session NFS13 logs on new silicon.
• Loyd (Mali-G615) — DMC5 + GTA V runs.
• DUCKTEN (Mali-G615) — NFS + AC3SP sessions.

Upstream DXVK Reference

• doitsujin/dxvk — based on DXVK v1.10.3 (upstream current: v3.1)

panDXVK v1.10.3-panVK.6 (Experimental)

panDXVK v1.10.3-panVK.6

Summary

v1.10.3-panVK.6 fixes the ASTC block encoding behind the BC→ASTC transcode. v1.10.3-panVK.5 stopped the force-on crash, but every remapped texture was written with a block that Appendix C of GL_KHR_texture_compression_astc_ldr allows a decoder to reject — wrong weight grid, reserved endpoint mode, weight stream at the wrong end of the block — which is why gameplay blocks corrupted while flat, desaturated UI art still looked close to correct. This release writes a spec-conformant block and adds the first ASTC round-trip gate the pipeline has ever had; until now every gate exercised only the BC half.

Key Features

• ASTC 4x4 block encoding conforms to Appendix C of GL_KHR_texture_compression_astc_ldr: a legal 4x4 weight grid, a legal weight range, a non-reserved endpoint mode, and the weight stream stored downward from block bit 127
• Weight indices ISE-packed to the range the block header actually declares (5 x 7-bit groups + 1 x 3-bit partial group = 38 bits) instead of raw 2-bit values it never announced
• Endpoints emitted in Mode-12 channel order (R0,R1,G0,G1,B0,B1,A0,A1)
• writeBits() widened to 64 bits so the 38-bit weight stream cannot be truncated, with static_asserts pinning the block layout

Installation

Option A — WCP (recommended):

1. Download pandxvk-1.10.3.wcp from the assets below.
2. In Winlator/Bannerlator, go to Container Settings → Content.
3. Tap Install and select the downloaded file.
4. Launch your game.

Option B — Manual DLL replacement:

1. Download merged.zip (x64 + x32 DLLs) from the assets below.
2. Extract the archive.
3. Replace d3d11.dll, dxgi.dll, d3d10.dll, d3d10_1.dll, d3d9.dll with the ones matching your container's architecture:
   • 64-bit folder (system32)
   • 32-bit folder (syswow64)
4. Launch your game.

Configuration

unchanged

Changelog

• Added:
  • quantizeWeightTo(), writeBlockHeader(), writeEndpoints() and packWeightQuints() helpers in util_astc_encode.h
  • decodeQuintGroup() / quintEncodeTable() — a local transcription of the spec's ISE quint unpack, used to drive weight packing
  • Six static_asserts pinning the block mode, endpoint-mode value, endpoint bit offset, the absence of endpoint/weight overlap, the weight stream's exact end position, and byte order (the weight stream is written bit-reversed)
• Changed:
  • writeBits() now takes uint64_t value and bounds-checks against the 128 block bits, so a 38-bit weight stream is not silently truncated
  • Weight indices are ISE-packed to the block's declared weight range (5 levels) rather than written as 2 bits the header never announced
• Fixed:
  • Gameplay texture corruption. encodeAstcBlock4x4() violated four independent rules of GL_KHR_texture_compression_astc_ldr Appendix C. Block mode 0x00A decodes as a 2x8 weight grid (a grid axis larger than the block footprint is an illegal block encoding that returns the error colour for every texel) and declares 1-bit weights while 2 bits were written per texel. writeBits(block, 11, 0x0C, 6) placed the endpoint-control field where the 2-bit Part field begins, so the real CEM at bits[16:13] read 3 — "Reserved for HDR" — instead of 12. Weights were written at bits[112:81] rather than stored downward from block bit 127. Mode-12 endpoints were written as two RGBA pairs instead of channel-interleaved R0,R1,G0,G1,B0,B1,A0,A1. Flat or desaturated UI art still decoded close enough to look correct, while coloured gameplay blocks did not.
  • The pipeline had no ASTC decoder anywhere in the tree, so no round-trip gate had ever been run against the encode side — the defect was invisible to every existing gate.
• Removed:
  • Nothing

Notes

• Reading d3d11.log — what proves the transcode actually ran. The authoritative markers are the one-time panDXVK: BC->ASTC remap VkImage… line plus panDXVK: SRV BC→ASTC / panDXVK: RTV BC→ASTC when views are created. The panDXVK: BC→ASTC transcode …us timings and the PANDXVK_FORCE_TRANSCODE=1 notice appear only on the UpdateSubresource path; titles that upload initial data through the D3D11 initializer legitimately show zero of both — that is not a gate failure. Success also means no d3d11+0x60731 backtrace. The gate is off only when there are zero remap lines, which prints panDXVK: BC->ASTC transcode unavailable once near the top of the log.
• Tester configuration (unchanged from v5). Set these where your launcher passes env to the game: PANDXVK_FORCE_TRANSCODE = 1, DXVK_LOG_LEVEL = debug, DXVK_LOG_PATH = /sdcard/Download. Both the force flag and the log level must reach the game — level alone silences all transcode diagnostics. All of these need a game restart to take effect.
• Set WRAPPER_NO_PATCH = 0 before testing. If you get a crash or black screen, revert it to 1.
• For now don't test with the PanVK driver — use the blob driver.
• Run a force-off control (PANDXVK_FORCE_TRANSCODE = 0) alongside. It should produce zero remap lines and is the baseline for any crash comparison.
• Zero remap lines means the driver reports textureCompressionASTC_LDR = 0, so the gate is correctly disabled — a driver-report problem, not a transcode problem. Report it with the Device properties: block.
• Enable wine logs in your Winlator version's settings so a wine_debug.log file is generated — d3d11.log alone cannot explain crashes.
• What to look for in v6. Gameplay textures that were hue-shifted and darkened in v5 should render correctly; splash screens and menus already looked close to correct and should be unchanged. The most useful report is screenshots of both a gameplay scene and a menu, plus the d3d11.log.
• D3D11 only. The D3D9 path is untouched, and d3d9 still forces textureCompressionBC at device creation — not covered by this fix.
• Known limitation: ASTC textures are not decoded on readback (Map of a transcoded texture returns ASTC bytes), so CPU-side readback of BC-origin textures is wrong on force-on runs.
• Based on DXVK v1.10.3. Upstream is at v3.1.

Credits

• doitsujin/dxvk — upstream DXVK
• pythonlover02/dxvk-sarek — Sarek fork
• Wonderkast — BC7/ASTC technical review, lead of panVK for Mali G720
• leegao/bcn_layer — BCN wrapper layer reference
• richgel999/bc7enc — BC7 differential oracle
• iOrange/bcdec — BC6H differential oracle (MIT)
• isygold/panDXVK-logs — community log repo

[Testers] Thank you:

• Gustave (Mali-G52) — Nine Sols, Silksong, Sugary Spire, GTA V logs plus the wine logs that named the crash. The most consistent logger we've had — every diagnosis this release traces back to your files. Genuinely appreciated.
• Us5rman (Mali-G615) — AIO/FPS baselines, FF7, MOTORSLICE, NFS reports that mapped the early territory.
• @UriYuanKerr69 (Mali-G52) — Cult of PiN (v2 + v3 builds with screenshots), Dead Cells, Streets of Rogue, Loopler reports.
• LORD (Mali-G720) — Silksong + long-session NFS13 logs on new silicon.
• Loyd (Mali-G615) — DMC5 + GTA V runs.
• DUCKTEN (Mali-G615) — NFS + AC3SP sessions.

panDXVK v1.10.3-panVK.5 (Experimental)

panDXVK v1.10.3-panVK.5

Summary

Experimental follow-up to v1.10.3-panVK.4. v4 shipped a latent crash that fired on every force-on run: imageFormatInfo() had no ASTC entries, so it returned nullptr and the D3D11 texture constructor dereferenced aspectMask at offset 0x0c — the d3d11+0x60731 page fault seen identically in all three of Gustave's titles, always one line after the first BC->ASTC remap VkImage. v5 registers the formats, enables textureCompressionASTC_LDR, collapses the three hand-synced remap gates into one shared predicate, and stops checkFeatureSupport()'s panVK bypass from handing vkCreateDevice a feature set it never reported. Not a final release — this is the decisive-test build.

Key Features

• ASTC 4x4 registered in the format table — imageFormatInfo() no longer returns nullptr for transcode targets
• textureCompressionASTC_LDR enabled from the supported set, so ASTC images are legal on the device
• One shared isPanVkTranscode() gate for texture / RTV / SRV — the three conditions can no longer drift apart
• panVK feature balance: the five features the probe bypasses are now masked at the vkCreateDevice boundary
• One-time panDXVK: BC->ASTC transcode unavailable… error when transcode is wanted but impossible

Installation

Option A — WCP (recommended):

1. Download pandxvk-1.10.3.wcp from the assets below.
2. In Winlator/Bannerlator, go to Container Settings → Content.
3. Tap Install and select the downloaded file.
4. Launch your game.

Option B — Manual DLL replacement:

1. Download merged.zip (x64 + x32 DLLs) from the assets below.
2. Extract the archive.
3. Replace d3d11.dll, dxgi.dll, d3d10.dll, d3d10_1.dll, d3d9.dll with the ones matching your container's architecture:
   • 64-bit folder (system32)
   • 32-bit folder (syswow64)
4. Launch your game.

Configuration

Set these environment variables where your launcher passes env to the game:

PANDXVK_FORCE_TRANSCODE = 1
DXVK_LOG_LEVEL = debug
DXVK_LOG_PATH = /sdcard/Download

Variable	Values	Description
PANDXVK_FORCE_TRANSCODE	0, 1	Force BC→ASTC on Mali even when the driver claims BC. Test knob, explicit CPU overhead. Needs game restart.
DXVK_LOG_LEVEL	none…debug	Both this AND force must reach the game — level alone silences all transcode diagnostics.
DXVK_LOG_PATH	path	Directory for log files.

Note:

• Set WRAPPER_NO_PATCH = 0 before test.( IF YOU EXPERIENCE CRASH OR BLACK SCREEN ON SET, REVERT BACK THE VALUE TO 1)
• For now don't test with the PanVK driver — use the blob driver.

Changelog

• Added:
  • VK_FORMAT_ASTC_4x4_UNORM / VK_FORMAT_ASTC_4x4_SRGB entries and a fifth format group in dxvk_format.cpp, with a static_assert tying the array size to the summed group span
  • DxvkAdapter::isPanVkTranscode() as the single source of truth for the remap gate
  • forceTranscodeEnabled() moved to util_env.h (DXGI-free, callable from the dxvk/ core layer)
  • One-time error log when transcode is wanted but the driver exposes neither BC nor ASTC
• Changed:
  • textureCompressionASTC_LDR is enabled from supported instead of left at default
  • panVK: geometryShader, multiViewport, shaderClipDistance, shaderCullDistance, textureCompressionBC are masked against the reported set at device creation — only when isPanVk() is true
  • Texture / RTV / SRV remap conditions collapsed onto the shared predicate
• Fixed:
  • The v4 force-on crash. imageFormatInfo() returned nullptr for every ASTC format (the table stopped at BC7 = 146, ASTC 4x4 = 157/158), so the texture constructor read aspectMask through a null pointer at struct offset 0x0c → d3d11+0x60731 page fault, always immediately after the first remap line. Reproduced in mo2, Nine Sols and Silksong.
  • Latent VK_ERROR_FEATURE_NOT_PRESENT: checkFeatureSupport() bypasses five features on panVK, but GetDeviceFeatures() still forced them VK_TRUE and createDevice handed that set to vkCreateDevice unfiltered.
• Removed:
  • Nothing

Notes

• Corrected Sep 25, 2026 — how to read d3d11.log. The authoritative success markers are the one-time panDXVK: BC->ASTC remap VkImage… line, plus panDXVK: SRV BC→ASTC / panDXVK: RTV BC→ASTC when views are created, and no d3d11+0x60731 backtrace. The panDXVK: BC→ASTC transcode …us timings and the PANDXVK_FORCE_TRANSCODE=1 notice are printed only on the UpdateSubresource path — titles that upload initial data through the D3D11 initializer (the common case) legitimately show zero of both. Absence of timings does not mean the gate turned itself off. The gate is off only when there are zero remap lines, and that case prints panDXVK: BC->ASTC transcode unavailable once near the top of the log.
• If there are zero remap lines: the driver reports textureCompressionASTC_LDR = 0, so the gate is correctly disabled. That is a driver-report problem, not a transcode problem — report it with the Device properties: block.
• Run a force-off control (PANDXVK_FORCE_TRANSCODE = 0) alongside. It should produce zero remap lines and is the baseline for any crash comparison.
• Enable wine logs in your Winlator version's settings so a wine_debug.log file is generated — the d3d11.log alone cannot explain crashes.
• D3D11 only. The D3D9 path is untouched, and d3d9 still forces textureCompressionBC at device creation — not covered by this fix.
• Known limitation: ASTC textures are not decoded on readback (Map of a transcoded texture returns ASTC bytes), so CPU-side readback of BC-origin textures is wrong on force-on runs.
• Based on DXVK v1.10.3. Upstream is at v3.1.

Credits

• doitsujin/dxvk — upstream DXVK
• pythonlover02/dxvk-sarek — Sarek fork
• Wonderkast — BC7/ASTC technical review, lead of panVK for Mali G720
• leegao/bcn_layer — BCN wrapper layer reference
• richgel999/bc7enc — BC7 differential oracle
• iOrange/bcdec — BC6H differential oracle (MIT)
• isygold/panDXVK-logs — community log repo

[Testers] Thank you:

• Gustave (Mali-G52) — Nine Sols, Silksong, Sugary Spire, GTA V logs plus the wine logs that named the crash. The most consistent logger we've had — every diagnosis this release traces back to your files. Genuinely appreciated.
• Us5rman (Mali-G615) — AIO/FPS baselines, FF7, MOTORSLICE, NFS reports that mapped the early territory.
• @UriYuanKerr69 (Mali-G52) — Cult of PiN (v2 + v3 builds with screenshots), Dead Cells, Streets of Rogue, Loopler reports.
• LORD (Mali-G720) — Silksong + long-session NFS13 logs on new silicon.
• Loyd (Mali-G615) — DMC5 + GTA V runs.
• DUCKTEN (Mali-G615) — NFS + AC3SP sessions.

Upstream DXVK Reference

• Based on: doitsujin/dxvk v1.10.3
• Upstream latest: v3.1
• Fork chain: dxvk → dxvk-sarek (pythonlover02) → panDXVK (isygold)