# Pure C++ PP-OCRv6 inference

This is a focused C++ port of the PP-OCRv6 detector/recognizer path from
`D:\workprj\aicoder\corelib\ocr`.  It has no dependency on ONNX Runtime,
Paddle Inference, OpenCV, or Python.

The library is also a C and C++ API (`include/ppocr/ppocr.hpp`,
`include/ppocr/ppocr.h`) with static and shared builds, CMake package
exports, and a Python package whose `RapidOCR` class follows the interface
on `main`. Usage, the stable C ABI, and the CPU dispatch rules are in
[`docs/API.md`](docs/API.md). Measured AVX2 / AVX-512 / NEON notes are in
[`docs/PERFORMANCE.md`](docs/PERFORMANCE.md).

The embedded executor is intentionally not a general ONNX Runtime.  It only
implements the operator set exercised by the official PP-OCRv6 tiny/small/
medium ONNX model bundle: convolutions (including transpose), pooling,
elementwise math, normalisation, resize, tensor-shape operators, attention
matmul, and softmax.

> **Current GPU-only qualification (2026-08-21).** The strict Vulkan
> GPU-only OCR path runs RGB preprocessing, the complete neural graph, DB
> postprocessing, and CTC Top-1 on the GPU; it has no CPU neural-operator
> fallback. On the local AMD Radeon 780M / LLPC stack, exact CPU/GPU decoded
> text and geometry are currently verified for PP-OCRv6 **tiny** and **small**.
> GPU recognizer crops
> now retain their exact PP-OCR aspect-ratio width rather than adding a
> 64-column scheduling suffix, fixing short-crop CTC parity. The **medium**
> detector at production `1x3x160x704` remains unqualified and fails closed;
> no result is substituted from CPU. Nearby `1x3x160x640` and `1x3x160x768`
> shapes remain CPU/GPU parity-qualified. Historical GPU claims below do not
> widen this current qualification.

### 2026-08-22 strict GPU-only public-boundary recheck

The public `gpu_only` mode remains a strict Vulkan-only execution path:
packed RGB upload and resize, detector and recognizer graphs, DB box
postprocessing, and CTC Top-1 execute on the device. Failed Vulkan execution
does not retry neural inference on CPU.

This recheck also carries the Vulkan queue/fence status through every public
GPU-only OCR stage (RGB front end, detector, DB postprocess, recognizer and
CTC). A device reset is therefore reported as `VK_ERROR_DEVICE_LOST`, not
mislabelled as an unsupported ONNX operator. The only retry allowed by the
GPU-only page batch scheduler is an N=1 Vulkan retry after a rejected N-batch;
it never invokes the CPU executor. On the local Radeon 780M / LLPC adapter,
production medium-detector `1x3x160x704` still fails closed with that result.
Changing command-segment size, forcing queue-idle, using a fresh command
buffer, using the isolated terminal-depthwise shader, or using its
generic/sliced variant did not make that shape stable. This is a driver
compatibility limit, not a CPU-fallback opportunity.

### 2026-08-22 GPU-only deployment coverage

`gpu_only` is a complete execution mode, not a request to accelerate only
selected layers: packed RGB upload/resize, detector, DB postprocess,
recognizer, CTC Top-1, and the real NCHW page/crop batch paths stay on one
Vulkan queue.  Only final compact OCR records and UTF-8 construction reach
the host.  A rejected N-batch is retried as strict Vulkan N=1; it is never
redirected to the CPU graph.

The Vulkan loader is dynamically opened at runtime, so applications do not
link to Vulkan or ONNX Runtime.  The build now embeds shaders with the
vendored Windows compiler when available, otherwise with a host
`glslangValidator`/`glslang`; the same executor is therefore buildable on
Windows x86/x64, Linux x86/x64, and Linux ARM/AArch64 when Vulkan headers and
a shader compiler are supplied.  If the loader, compute queue, shader build,
or a required graph node is unavailable, constructor/runtime validation fails
closed rather than selecting CPU inference.

After this portability change, the local Radeon 780M validation was rerun
with the rebuilt `build-gpu-only-ep` binaries:

| Check | Result |
| --- | --- |
| tiny GPU-only OCR, `en` + `mixed` + low contrast, 2 repeats | passed; 8 records; max confidence delta `2.50e-5` |
| small GPU-only OCR, `en` + `mixed` | passed; 5 records; max confidence delta `1.0e-6` |
| tiny two-page GPU batch, `en` x2, 1 warm-up + 5 runs | serial `93.109 ms`, batch `84.491 ms`, `1.102x`; text/geometry equivalent |
| tiny GPU memory ladder, 16px through 1920px pages then back to small | all requests completed; post-large small/en/mixed returned to the warmed `596,709,376 B` private-byte baseline |

The last memory sweep later rose by at most `9,392,128 B` after a noisy page
and finished `7,172,096 B` above that process allocator baseline.  This is a
bounded host allocator effect observed after the request; it is not reported
as GPU arena growth and does not relax the device-only inference contract.

### 2026-08-22 expanded GPU-only corpus recheck

The correct PP-OCRv6 common dictionary (`dict_ppocrv6.txt`, vocabulary
`18710`) was used for small/medium rather than the tiny dictionary.  The
latest strict GPU-only corpus covers low contrast, very wide/tall source
images, and a 1920×1080 screenshot in addition to short English/mixed text:

| Model | Images | Result |
| --- | --- | --- |
| tiny | `en`, `mixed`, low contrast, `3000×80`, `80×3000`, screenshot; 2 repeats | passed; 63 records; exact decoded text/geometry; max confidence delta `1.1662e-3` |
| small | same six images | passed; 63 records; exact decoded text/geometry; max confidence delta `2.265e-4` |
| medium | complete OCR at production detector shape | unavailable on this Radeon 780M/LLPC driver: strict `VK_ERROR_DEVICE_LOST`; no CPU substitution |

The independent neural-graph checks remain passed for tiny/small
`1×3×160×704` and medium `1×3×160×640`, with maximum CPU/GPU errors
`5.63276e-7`, `3.05939e-7`, and `7.56991e-8` respectively. Small-model memory
through the same small-to-large ladder returned to its warmed baseline after
the final screenshot (`1,020,276,736 B` private bytes); a low-contrast request
briefly added `14,577,664 B` in the process allocator and the final screenshot
was below baseline. `ui_dense_1920x1080` is deliberately excluded from the
qualified OCR corpus: it currently has one CPU/GPU decoded-result mismatch.
That failure is retained as a regression target rather than being masked by a
fallback or presented as a pass.

The rebuilt `build-gpu-only-ep` binaries passed the currently qualified
coverage. The graph timing measurements below use two warmed runs on the same
machine and include the current host/device graph boundary:

| Check | Result |
| --- | --- |
| tiny detector graph, `1x3x160x704` | passed; max error `5.63276e-7`; CPU/GPU `10.590 / 45.256 ms` |
| small detector graph, `1x3x160x704` | passed; max error `3.05939e-7`; CPU/GPU `18.676 / 66.362 ms` |
| medium detector graph, `1x3x160x640` | passed; max error `7.56991e-8`; CPU/GPU `80.312 / 272.255 ms` |
| GPU-only OCR tiny, `en` + `mixed` | passed; 5 records; max confidence delta `2.9e-6` |
| GPU-only OCR small, `en` | passed; 2 records; max confidence delta `8e-7` |
| true two-page GPU batch, tiny `en` x2 | serial-equivalent; `93.177 -> 90.993 ms` (`1.024x`) |
| true two-page GPU batch, small `en` x2 | serial-equivalent; `239.759 -> 231.595 ms` (`1.035x`) |

The medium detector memory ladder
`64x128 -> 96x256 -> 128x512 -> 160x640 -> 64x128` also passed. At every
phase the live allocation returned to the `61,946,548`-byte immutable
constants baseline; reusable capacity reached `201,457,664` bytes and is
intentionally retained for later requests. These results validate qualified
GPU-only execution and recovery behavior, but do not claim that this UMA GPU
is faster than the AVX-512 CPU or an ORT GPU provider.

The public GPU-only memory ladder also covered, in increasing source-size
order, `tiny_16x16`, `en`, `mixed`, `noisy_lowcontrast`, `wide_strip_3000x80`,
`tall_strip_80x3000`, `screenshot_1920x1080`, and `ui_dense_1920x1080`.
After the final large image, processing the next small image retained no extra
private bytes above the warmed large-page baseline. A later noisy page can
make the process allocator grow by about 12 MB for compact host result/control
storage; that allocation stayed bounded through the remaining large pages.
GPU replay command buffers and their pinned slots are now discarded whenever
the model uses the bounded detector/recognizer hand-off policy, so old replay
shapes cannot accumulate as device allocations.

### 2026-08-22 hybrid Vulkan admission correction

Hybrid terminal CTC GEMM now follows the documented policy exactly: for the
same model shape, CPU worker budget, Vulkan adapter, and Vulkan runtime
generation, it is admitted when a complete upload/compute/download boundary
is **no slower than CPU**. The older `GPU <= CPU / 2` rule could reject an
equal-speed GPU path merely because multiple recognizer crops might execute
concurrently on CPU. Queue serialization is instead controlled at the OCR
scheduler boundary. The admission cache is now also tagged with the Vulkan
runtime generation, so a device-loss rebuild always re-measures rather than
reusing an answer from the old device.

On this Radeon 780M host, tiny `en` CTC terminal shapes measured `1.361 /`
`0.718 ms` and `1.846 / 1.281 ms` for GPU/CPU, so they correctly remain CPU
on this adapter. This is expected: the implementation enables Vulkan only on
actual no-slower results, and does not manufacture a GPU claim from a slower
boundary. The hybrid batch regression (`tiny_16x16`, `en`, `mixed`, low
contrast; 2-page scheduling) remained text/geometry equivalent and measured
`67.358 -> 63.918 ms` (`1.054x`).

### 2026-08-21 GPU-only requalification

#### Latest local recheck

The strict Vulkan build was rebuilt after removing an unproven automatic
generic-tail experiment. The standard terminal scalar depthwise selection is
restored for qualified shapes. The following tests were rerun on AMD Radeon
780M / LLPC; all use the pure C++ implementation without ONNX Runtime:

| Check | Result |
| --- | --- |
| tiny detector graph, `1x3x160x704` | passed, max error `5.63276e-7` |
| medium detector graph, `1x3x160x640` | passed, max error `7.56991e-8` |
| medium detector graph, `1x3x160x768` | passed, max error `3.25672e-8` |
| medium recognizer graph, `1x3x48x320` | passed, max error `2.66433e-5` |
| GPU-only OCR tiny, `en` + `mixed` | passed; 5 records; max confidence delta `2.9e-6` |
| GPU-only OCR small, `en` | passed; 2 records; max confidence delta `8e-7` |
| tiny graph memory ladder, `64x128 -> 96x256 -> 128x512 -> 160x704 -> 64x128` | passed; live device bytes always returned to `1,713,924` B |

The production medium detector at `1x3x160x704` still returns
`VK_ERROR_DEVICE_LOST` on this driver after the terminal `896x5x22` depthwise
stage. With the normal 20-node segmentation the failure is observed on the
segment ending at that stage; a diagnostic command-stream grouping can submit
that tail and subsequently fails in the FPN head. This identifies a
Radeon 780M/LLPC Vulkan command-stream stability issue rather than a usable
CPU fallback point. It remains deliberately fail-closed: no CPU neural or
postprocess substitute is used. This blocks a claim of complete all-model
GPU-only qualification on the local adapter.

The end-to-end GPU path was rebuilt from the conservative source and retested
on Radeon 780M/LLPC. A GPU crop may use a dynamic width; it is no longer
rounded to 64 columns, because padded input columns produce extra valid
CNN/CTC time rows and can alter a short crop's text or confidence.

| GPU-only OCR pair | Corpus | Result |
| --- | --- | --- |
| tiny | `tiny_16x16`, `en`, `noisy_lowcontrast`, `wide_strip_3000x80` | 7 results; exact text/geometry; max confidence error `2.50e-5` |
| tiny replay | `en` repeated 5 times on one live OCR instance | 10 results; exact text/geometry; max confidence error `4e-7` |
| small | `en`, `noisy_lowcontrast` | 5 results; exact text/geometry; max confidence error `1.3e-6` |

The strict graph sweep (three runs except medium detector, two) also passed:
tiny detector `9.367 / 28.870 ms` CPU/Vulkan, tiny recognizer `5.224 / 23.189
ms`, small detector `17.976 / 48.075 ms`, small recognizer `13.320 / 62.323
ms`, medium recognizer `30.569 / 123.212 ms`, and the qualified medium
detector shape `1x3x128x704` `78.976 / 234.478 ms`. These are full graph
latencies on this UMA GPU, not an assertion that it beats the AVX-512 CPU.
Maximum graph-output errors were `5.63e-7`, `2.18e-5`, `3.06e-7`, `3.78e-4`,
`2.66e-5`, and `6.71e-9` respectively.

GPU arena recovery was also rerun after the correction. In every small-to-
large-to-small phase, dynamic `activation_bytes=0` after completion:

| Graph ladder | Immutable live baseline | Final reusable capacity |
| --- | ---: | ---: |
| tiny detector through `1x3x160x704` | 1,713,924 B | 47,513,600 B |
| small detector through `1x3x160x704` | 9,813,844 B | 75,235,328 B |
| medium recognizer through `2x3x48x320` | 76,456,140 B | 174,850,048 B |

### 2026-08-21 verification update

The strict GPU graph replay policy was corrected for public host-input
`Run()` calls.  Replay remains enabled for device-input and in-graph RGB
execution, while host-input calls now release their dynamic activation slots
when the submission completes.  This is an arena-lifetime change only: every
neural operator remains a Vulkan dispatch and an unsupported or failed device
operation still fails closed.

The reproducible tiny-detector ladder
`1x3x64x128 -> 1x3x96x256 -> 1x3x128x512 -> 1x3x160x704 -> 1x3x64x128`
now passes `ppocr_gpu_graph_mem_soak`.  Its immutable live baseline is
**1,713,924 bytes**; after every sample, including the largest one, live
bytes return exactly to that baseline.  Reusable arena capacity grows to
**47,513,600 bytes** at the largest input and intentionally stays available
for the final small input, so capacity is not misreported as a live-memory
leak.

The same live-memory invariant also passed for the qualified medium-detector
ladder ending at `1x3x160x640`: its **61,946,548-byte** immutable baseline
was recovered after each sample, with a stable **216,072,192-byte** reusable
high-water capacity.

The medium detector was rechecked at the production `1x3x160x704` input.
On this Radeon 780M/LLPC driver it still fails closed with
`VK_ERROR_DEVICE_LOST` in the terminal `896x5x22` depthwise dispatch. The
dedicated scalar shader is now selected automatically for that exact Vulkan
operator (use `PPOCR_GPU_TAIL_GENERIC=1` only for diagnostics); it also fails
closed on this production shape, as did device-local and host-cached arena
variants. The nearby qualified `1x3x160x640` and `1x3x160x768` shapes pass
CPU/Vulkan output comparison, which further confirms this is a driver/shape
interaction rather than a CPU fallback.

Hybrid RGB front ends are now admission-driven by default: detector RGB+stem
and recognizer RGB+Conv.0 run only after their complete upload/dispatch/
readback boundary is both numerically validated and no slower than the native
SIMD path. `PPOCR_DISABLE_VULKAN_RGB_STEM` and
`PPOCR_DISABLE_VULKAN_REC_RGB_CONV` disable those probes for diagnostics; no
enable-only switch is required.

The default strict-graph command segment is now **20 nodes** (override with
`PPOCR_GPU_ONLY_SEGMENT_NODES`).  A fresh three-run Vulkan sweep selected that
setting for the Radeon 780M: detector graph means were tiny `30.201 ms`,
small `46.590 ms`, and qualified medium `239.388 ms`; recognizer means at
`1x3x48x320` were tiny `23.169 ms`, small `60.031 ms`, and medium
`123.182 ms`.  CPU/Vulkan maximum output errors remained respectively
`5.63e-7`, `3.06e-7`, `6.71e-9`, `2.18e-5`, `3.78e-4`, and `2.66e-5`.
This is a segment-lifetime optimization, not an assertion that the local UMA
GPU is faster than the AVX-512 CPU.

Memory recovery was also exercised across detector resolution and recognizer
width/batch diversity.  Small detector `64x128 -> 96x256 -> 128x512 ->
160x704 -> 64x128` always returned to its **9,813,844-byte** constants
baseline.  The medium recognizer ladder `1x3x48x64 -> 1x3x48x160 ->
1x3x48x320 -> 2x3x48x320 -> 1x3x48x64` always returned to its
**76,456,140-byte** constants baseline.  Capacity is intentionally retained
as reusable GPU storage; no dynamic activation remains live after a sample.

The CPU batch executor now supports real same-shape detector NCHW batches
through both fused `MaxPool -> Concat -> Conv` and `Concat -> Conv` nodes.
Those nodes now advance each source by its own NCHW channel-plane stride, so
unequal concat branches cannot cross-contaminate pages. The varied-size
four-image detector-batch regression passes for tiny/small/medium: decoded
text and geometry are exact, while FP32 confidence is checked against its
documented bounded tolerance. `rec_batch_size` now defaults to `1` because
this PP-OCRv6 transformer export can change CTC results for N>1 recognition
crops; deployments may still opt in and qualify it independently. GPU-only
retains its separate device-resident crop batching path.

The full small-to-large-to-small memory ladder (19 images, including
`5120x2880`, `7680x4320`, wide and tall aspect ratios) also passed for every
CPU model.  Per-resolution private-byte and working-set evidence is retained
in `build-gpu-only-final/memory_ladder_{tiny,small,medium}_cpu_20260821.json`.
In each run both counters fell below the post-8K high-water during the
recovery tail; final-small private memory was within **-0.05% / +0.33% /
+1.06%** of the warmed tiny/small/medium baselines respectively.

The current five-image CPU comparison is recorded in
`build-gpu-only-final/cpu_diverse_benchmark_20260821.json`. On this local
AVX-512 host (16 threads, two warmups, eight runs per case), native C++ beat
the installed ONNX Runtime 1.28.0 CPU provider on every case:

| PP-OCRv6 model | weighted latency improvement | weakest case |
| --- | ---: | ---: |
| tiny | 73.54% | 63.33% |
| small | 46.16% | 36.22% |
| medium | 9.22% | 1.45% |

This is a local CPU-only result. The installed ORT package lists
`AzureExecutionProvider` and `CPUExecutionProvider`; its observed variance,
especially on small inputs, means these figures are not a portable GPU or
architecture-wide claim.

## CPU acceleration and architecture support

The inference path remains dependency-free and portable across x86/x64 and
ARM/AArch64. Hot contiguous elementwise paths (Add/Sub/Mul/Div, ReLU,
HardSwish, and affine scale/shift),
pointwise `1x1` convolutions, ordinary/depthwise `3x3`/`5x5` convolutions,
spatial mean reduction, fused BatchNorm+GELU, and attention `MatMul` use
fused vector kernels:

- x86/x64: AVX-512F/FMA when supported by the running CPU and OS; otherwise
  AVX2/FMA; otherwise scalar code. Advanced ISA code is compiled into separate
  translation units and selected only after runtime CPUID/OS-state checks.
- ARM/AArch64: NEON when the compiler/target exposes it, with a scalar
  fallback otherwise.
- Larger GEMMs are divided over CPU cores; small GEMMs stay single-threaded to
  avoid thread-launch overhead. Direct convolutions use a persistent worker set
  (rather than creating threads per operator), defaulting to at most 16 workers;
  `PPOCR_BENCH_THREADS` is an explicit override for deployment tuning and A/B
  tests.
- PPOCR_DISABLE_AVX512=1 is an optional per-process A/B switch for x86
  deployments. It keeps all runtime safety checks and selects AVX2/FMA when a
  particular AVX-512 CPU or workload performs better at its non-AVX-512 clock.
- `ppocr_kernel_smoke` verifies paired/odd GEMM rows, scalar/vector column
  tails, optional bias, and a recognizer-sized projection. Run it normally and
  with `PPOCR_DISABLE_AVX512=1` to cover the dynamic AVX-512 and AVX2 paths.
- PPOCR_DISABLE_AVX512_POINTWISE8=1 is a narrower A/B switch for the AVX-512
  eight-output `1x1` register tile. It retains AVX-512 and its four-output
  pointwise kernel, so deployments can isolate this tile's cache/register
  trade-off without changing the baseline ISA. A current three-model A/B
  confirmed that this decision is shape-sensitive: do not globally force the
  wider tile merely because AVX-512 is available.
- PPOCR_ENABLE_AVX512_POINTWISE_RELU8=1 opt-in enables the analogous
  eight-output `1x1 Conv+ReLU` tile for deployment-local testing. The stable
  four-output fused-ReLU path remains the default because the wider tile's
  end-to-end result is workload/cache sensitive.
- Large stride-one `3x3` feature maps can likewise use an AVX-512 eight-output
  channel tile. It shares each input vector across eight output reductions;
  the dispatcher restricts it to maps of at least 16,384 pixels and falls back
  to the four-output tile for smaller layers, odd channel tails, AVX2, NEON,
  and scalar targets. `PPOCR_DISABLE_AVX512_CONV3X3_TILE8=1` keeps the
  four-output AVX-512 path for deployment A/B. The low-level regression now
  checks both an eight-channel tile and a nine-channel ReLU tail, which also
  caught and fixed the prior un-clamped SIMD tail-channel bug.
- AVX-512 also has a dedicated unit-stride `2x2 SAME_UPPER` convolution path
  for the detector reconstruction stem. Its large valid interior uses four
  explicit FMA loads per input channel; only the final row/column runs the
  ONNX zero-padding boundary formula. It is dynamically selected only on a
  supported AVX-512 CPU, preserves the AVX2/scalar fallback, and can be A/B
  disabled with `PPOCR_DISABLE_AVX512_CONV2X2_SAME=1`.
- Equal-shape residual `1x1 Conv -> Add` pairs are fused at graph load and,
  on a runtime-eligible AVX-512, AVX2, or NEON CPU, keep the convolution
  accumulators live until the final residual add/store. This removes the
  intermediate Conv activation read/write. The executor validates the
  residual's runtime NCHW shape before selecting that kernel; scalar,
  broadcast, and unexpected-shape cases retain the existing exact
  Conv-then-Add path.
- Post-folding `Conv -> Sigmoid` and `Conv -> HardSigmoid` gate pairs are
  also fused. Their convolution result is activated in place, removing the
  generic unary output allocation; HardSigmoid uses one exact SIMD pass for
  `clamp(alpha*x+beta, 0, 1)` on AVX-512, AVX2, and NEON.
- Direct `Conv -> Add([1,C,1,1])` channel biases are folded into immutable
  convolution biases at graph load. If the Add is followed by ReLU, the three
  operations become one fused Conv+ReLU node. This covers the recognizer stem
  and avoids a full NCHW broadcast traversal and activation allocation.
- Recognition `Conv -> Sigmoid -> Mul` Swish gates are recognized after
  Conv+BatchNorm folding. The fused node writes `x * sigmoid(x)` directly into
  the Conv destination, eliminating the two branch activation tensors while
  retaining the exact FP32 operation order. The standalone BatchNorm variant
  follows the same rule when a model cannot fold the affine layer.
- `PPOCR_APPROX_GELU=1` is an opt-in PP-OCRv6 deployment mode for eligible
  model-aware fused BatchNorm+GELU planes. Its AVX-512/AVX2 dispatch is based
  on per-plane shape rather than total batch size, so batching cannot change a
  page's GELU implementation; generic GELU retains exact ONNX Erf semantics.

Model constants are no longer copied for every `Run()` invocation: they stay
in the immutable model store and execution allocates only inputs and temporary
tensors.  This substantially lowers peak transient memory usage for the
detector/recognizer.

Example cross builds (use the appropriate compiler/toolchain installed by your
environment):

```powershell
# Native ARM64 build (Visual Studio developer prompt)
cmake -S . -B build-arm64 -A ARM64
cmake --build build-arm64 --config Release

# Cross build using an ARM64 CMake toolchain file
cmake -S . -B build-aarch64 -DCMAKE_TOOLCHAIN_FILE=toolchains/aarch64.cmake
cmake --build build-aarch64 --parallel
```

The generic executor is not compiled for a host-specific ISA, avoiding
accidental illegal instructions on older x86 CPUs and on ARM targets. The
AVX-512 path remains the default on a supported CPU, while the switch is kept
for deployment-specific validation.

## ONNX Runtime comparison benchmark

The repository contains a repeatable CPU-only benchmark. It compares the
complete detector + recognition pipeline on the same PPM image, uses ONNX
Runtime's `CPUExecutionProvider`, warms up both engines, and reports mean,
median, p95, load latency and throughput.

```powershell
cmake -S . -B build -G "MinGW Makefiles"
cmake --build build --parallel
powershell -ExecutionPolicy Bypass -File .\bench\compare.ps1 -Runs 20 -Warmup 3
```

### 2026-08-14: wider correctness corpus and normalization A/B

The regression runner now accepts a UTF-8-BOM JSON case manifest as well as
plain UTF-8. This makes a small PowerShell-authored subset reproducible rather
than failing before inference. The current native validation covered all three
models against ONNX Runtime text output on English, Chinese, and `3000x80`
wide text (`3/3` cases each):
`build/accuracy_default_preprocess_ab_{tiny,small,medium}_20260814.json`.

Stress coverage also includes dense UI, tall text, and a `2560x1440`
screenshot. Tiny completed all 11 built-in cases; focused high-cost samples
completed for small (`3/3`) and medium (`2/2`), including 38 medium screenshot
regions. Reports are under `build/stress_*_current_20260814.json`.

Preprocessing retains its exact fused bilinear + normalization path. A compact
256-entry uint8 normalization lookup implementation was evaluated, but it
regressed medium on this AVX-512 host due to indexed-load/cache pressure. It
therefore remains an opt-in A/B switch (`PPOCR_ENABLE_PREPROCESS_NORMALIZE_LUT=1`)
rather than changing the production default. The paired result is recorded in
`build/bench_preprocess_lut_ab_current_20260814.json`; this keeps the default
chosen by measured end-to-end performance, not by a microbenchmark assumption.

The runtime AVX-512 dispatch remains dynamic: its current 15-run English A/B
against the AVX2 fallback measured **29.520 vs 34.133 ms** (tiny), **56.578 vs
80.106 ms** (small), and **212.366 vs 323.044 ms** (medium). See
`build/bench_avx512_dynamic_current_20260814.json`. Vulkan smoke continues to
pass on AMD Radeon 780M and admits the channel-affine+Swish and depthwise+Swish
GPU segments only when their complete transfer/dispatch/readback timing is no
slower than CPU. GPU-only correctly refuses construction until the complete
PP-OCRv6 device graph exists; it never silently runs CPU work.

`compare.ps1` now treats the requested performance target as a gate. Its
`-MinImprovementPercent` parameter defaults to `30`, and it returns a non-zero
exit code when end-to-end native latency is not at least that much lower than
the paired ONNX Runtime CPU measurement. Set it explicitly when a deployment
uses a different threshold.

`bench/ort_bench.py` requires `onnxruntime`, `numpy`, and Pillow in the Python
environment chosen by `bench/compare.ps1`. `ppocr_bench` keeps the native OCR
instance alive during all warmup/measurement iterations, so model parsing and
weight loading are excluded from steady-state latency just as they are in the
ONNX Runtime side.

### Latest measured result

The latest comparison is two consecutive `bench/compare.ps1` runs (tiny
det+rec, `build/regression_ppm/en.ppm`, `PPOCR_BACKEND=cpu`, 16 threads, 3
warmup / 20 measured, `PPOCR_APPROX_GELU` unset) captured on 2026-08-20 after
fusing the inverted-residual `1x1 expand → exact GELU → 1x1 project → residual
Add` into one spatial-tiled AVX-512 kernel (10 detector + 7 recognizer sites),
plus the prior AVX-512 stem/FPN/GEMM path. Model loading is excluded from
steady-state time. Figures are copied from those two JSON blobs; they are not
averaged into a third number.

| Run | Engine | Mean latency | Throughput | C++ / ORT | Latency improvement |
|---|---|---:|---:|---:|---:|
| 1 | Pure C++ PP-OCRv6 | 20.972 ms | 47.682 FPS | 0.208x | 79.16% |
| 1 | ONNX Runtime 1.28 CPUExecutionProvider | 100.631 ms | 9.937 FPS | | |
| 2 | Pure C++ PP-OCRv6 | 20.973 ms | 47.681 FPS | 0.209x | 79.15% |
| 2 | ONNX Runtime 1.28 CPUExecutionProvider | 100.588 ms | 9.942 FPS | | |

Both runs used `faster_engine = ppocr_cpp`. Native median/p95 were
20.884/23.443 ms and 20.376/23.720 ms. Relative to this change's pre-change
native ceiling of 30.280 ms, the pair is 30.7% / 30.7% lower latency
(each mean ≤ 21.196 ms). This is a host-specific result, not a portable
performance guarantee; rerun on the deployment CPU before capacity planning.

The previous pair after AVX-512 stride-2 tiles / fused MaxPool+Concat / FPN
Concat+Conv was 24.721 / 24.887 ms native vs 125.828 / 102.010 ms ONNX Runtime
(80.35% / 75.60%). The AVX2 exact-Erf GELU pair was 26.397 / 26.357 ms vs
99.273 / 111.544 ms (73.41% / 76.37%). The longer 60-run snapshot (2026-08-11,
8 warmup) on `build/en.ppm` was 33.074 ms native vs 138.359 ms ONNX Runtime.
Keep those as historical context only; the table above is the current
`compare.ps1` pair.

Reproduce the benchmark with:

```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File .\bench\compare.ps1 `
  -Runs 20 -Warmup 3 -Threads 16 -Backend cpu `
  -NativeExe .\build-gpu-only-final\ppocr_bench.exe
```

`bench/compare.ps1` drives the tiny pair. For small/medium, invoke
`build/ppocr_bench.exe` and `bench/ort_bench.py` directly with their matching
models and dictionary, as shown by the commands below.

### Current three-model CPU comparison

After the ARM/NEON GEMM bias-broadcast correction, the current x86 AVX-512
build was rerun on `build/en.ppm` with `PPOCR_BENCH_THREADS=16`, three warmups,
and ten timed runs per engine. The native and ONNX Runtime runs use the same
detector/recognizer pair, complete OCR pipeline, image, thread budget, and
warmup/run counts. This is a fresh shared-host snapshot rather than a portable
guarantee, but it confirms that all three supported PP-OCRv6 sizes remain well
ahead of ONNX Runtime CPUExecutionProvider:

| Model | Pure C++ mean | ORT mean | C++ / ORT | C++ latency reduction |
|---|---:|---:|---:|---:|
| tiny | 29.757 ms | 142.158 ms | 0.209x | 79.1% |
| small | 63.395 ms | 198.205 ms | 0.320x | 68.0% |
| medium | 191.198 ms | 374.134 ms | 0.511x | 48.9% |

The corresponding native throughput was 33.606, 15.774, and 5.230 FPS,
compared with ORT's 7.034, 5.045, and 2.673 FPS. Re-run the paired commands on
the deployment hardware before using these values for capacity planning.
The scalar/NEON GEMM fallback was also corrected to broadcast the bias by
output column (the same semantics as AVX-512/AVX2), rather than incorrectly
using one bias value for a whole output row. This is a correctness fix for
ARM targets and does not change the dynamically dispatched x86 measurements.

### 2026-08-13: refreshed long three-model CPU/ORT comparison

After the AVX-512 stride-one `3x3` eight-output tile was revalidated as the
default on all three model sizes, the complete `en.ppm` OCR pipeline was
rerun with 16 native/ORT CPU workers, five warmups, and 40 timed iterations
per engine.  This is the longer same-host measurement; it includes detector,
crop construction, recognizer, and decoding, but excludes model loading from
steady-state latency.  ORT used CPUExecutionProvider only.

| Model | Pure C++ mean | ORT mean | C++ / ORT | C++ latency reduction |
|---|---:|---:|---:|---:|
| tiny | 32.244 ms | 119.475 ms | 0.270x | 73.0% |
| small | 67.857 ms | 151.359 ms | 0.448x | 55.2% |
| medium | 220.768 ms | 365.267 ms | 0.604x | 39.6% |

All three exceed the repository's 30% paired CPU performance gate on this
host.  The benchmark samples remain machine-specific and ORT has wider timing
variation on this shared Windows host; full raw measurements are retained in
`build/compare_three_models_tile8_long_20260813.json`, so this table is not a
cross-platform guarantee.

### 2026-08-11: refreshed three-model exact CPU comparison

A fresh paired short run on `regression_ppm/en.ppm` used the same complete
OCR pipeline, matching 16-thread budgets, three warm-ups, and ten timed runs.
AVX-512 was dynamically selected on this x86 host; no approximation mode was
enabled.  The native and ORT measurements were executed separately on a shared
Windows machine, so these are reproducible evidence for this host閳ユ攺ot a
portable capacity promise.

| Model | Pure C++ mean | ORT mean | C++ / ORT | C++ latency reduction |
|---|---:|---:|---:|---:|
| tiny | 31.251 ms | 129.990 ms | 0.240x | 76.0% |
| small | 70.912 ms | 201.911 ms | 0.351x | 64.9% |
| medium | 199.734 ms | 409.505 ms | 0.488x | 51.2% |

This refresh keeps all three PP-OCRv6 sizes above the requested 30% native
CPU latency advantage on the same exact input. It follows the recognizer
executor lifetime fix that now executes `FusedBatchNormSwishAdd` in the
terminal-CTC path as well as the ordinary graph executor. The path reuses the
dying BatchNorm activation for affine + exact Swish + shortcut Add, reducing
the live feature-map frontier for small/medium crop batches. A profile confirms
the node as `ctc:FusedBatchNormSwishAdd:BatchNormalization.2_swish_add`.

The batch/memory follow-up used six varied PP-OCRv6 tiny inputs閳ユ攩rom `16x16`
through a `3000x80` strip閳ユ敋ith English, Chinese, and mixed content. Serial and
`RecognizeBatch()` outputs were identical (10 total results); bounded two-page
scheduling measured **134.218 ms serial / 86.501 ms batch (1.552x)**. A
medium-model memory cycle spanning `16x16`, mixed text, and a dense
`1920x1080` page used 369,672,192 private bytes after warm-up and finished at
+3,145,728 bytes. This is a Windows allocator high-water observation, not a
leak assertion; it bounds the varied-shape batch check to a small transient
increase rather than retaining every crop workspace.

## Vulkan backend status

The public API now exposes `ppocr::Backend::{cpu_only,gpu_only,hybrid}` and
`QueryBackendInfo()`. Runtime Vulkan probing is compiled from vendored Khronos
headers and dynamically loads `vulkan-1.dll`, so the binary does not require a
Vulkan SDK installation on its deployment machine. A generated SPIR-V compute
shader and smoke executable validate FP32 Add/Sub/Mul/Div building blocks over
scalar, non-workgroup-aligned, and recognizer-scale tensor sizes.
On this host, `ppocr_demo --backend-info` and `ppocr_vulkan_smoke` report the
AMD Radeon 780M compute queue and pass those correctness checks.

`gpu_only` deliberately fails if a complete PP-OCRv6 GPU graph is not
available; it never silently falls back to CPU. `hybrid` now connects verified
equal-shape in-place Add/Sub/Mul/Div executor nodes and eligible `1x1` Conv
nodes to Vulkan. For NCHW recognition tensors it maps N to the shader's Y
dimension, so a same-width crop batch uses one submission instead of one
submission per crop. A cached
per-shape/per-operation admission benchmark validates results and includes
host/device transfer, dispatch, and readback before it may select GPU; all
other operators remain on the portable CPU path. The Vulkan loader, instance,
device, queue, pipeline, descriptor set, command buffer, and grow-only
host-visible buffers are persistent, avoiding a per-dispatch Vulkan rebuild.

### 2026-08-12: depthwise GPU activation fusion

The batched Vulkan depthwise primitive now fuses its directly following
`ReLU` or exact `Swish` into the convolution writeback.  This covers the
common PP-OCRv6 MobileNet depthwise-gate shape without creating a CPU-side
activation pass or an intermediate host tensor.  The runtime still performs
shape-specific full-boundary admission (H2D, dispatch, fence, D2H, and CPU
SIMD comparison), and the new Vulkan smoke case validates batched odd-size
depthwise+Swish values against the scalar reference.  It is therefore a
batch-capable hybrid building block, not a claim that the still-partial GPU
graph is universally faster; `gpu_only` remains unavailable.

On the local Radeon 780M, the `N=4,C=32,H=31,W=29,3x3` admission sample was
**0.36344 ms GPU vs 0.62156 ms CPU**, so hybrid selected the fused GPU path.
The unfused depthwise sample in the same run was **0.33214 ms GPU vs 0.34084
ms CPU**. These figures include all transfers and synchronization and are
recorded as a per-segment comparison, not an end-to-end OCR claim.

The same depthwise kernel now also has a fused exact HardSwish variant for
PP-OCRv6 MobileNet blocks.  Its smoke admission sample measured **0.32760 ms
GPU vs 0.32076 ms CPU**, so hybrid correctly retained CPU for that shape;
the decision is dynamic rather than a blanket GPU preference.

### 2026-08-12: five-size batch and memory recheck

After the depthwise fusion work, CPU and hybrid `RecognizeBatch()` were
rechecked against serial execution on five deliberately different inputs:
`16x16`, English text, low-contrast text, a `3000x80` ultra-wide strip, and
CJK. All three official model sizes preserved exactly the same nested OCR
results. With one page worker, `det_batch_size=4`, and `rec_batch_size=4`, the
CPU measured serial/batch pairs were tiny **204.163/190.580 ms (1.071x)**,
small **392.496/375.710 ms (1.045x)**, and medium
**1260.420/1304.108 ms (0.967x)**. This mixed-shape result confirms that
batching is bounded-capacity scheduling rather than an unconditional latency
promise. The corresponding hybrid run was also result-identical (tiny
**204.311/210.308 ms**, small **436.332/411.353 ms**, medium
**1420.791/1461.834 ms**).

For compatible same-shape work, eight `en.ppm` pages with `det_batch_size=8`
and `rec_batch_size=8` measured **1.485x** CPU page-batch throughput for tiny
and **1.201x** for small. Medium did not benefit in that shared-host sample
(**0.911x**), and is therefore left with the conservative defaults rather
than promoting a batch size that regresses it. A two-cycle five-size tiny
memory soak started from **137,195,520 bytes** after warm-up and ended at
**+32,768** then **-151,552 bytes**, showing no retained per-shape activation
frontier.

Decoded-text comparison against ONNX Runtime was also rerun after these
changes for tiny, small, and medium on four diverse dimensions (`16x16`,
English, low-contrast, and `3000x80`): all **12/12** cases passed.

### 2026-08-12: GPU-aware batch regression refresh

The GPU and batch paths were rerun after the latest Vulkan/CPU optimization
pass. The public `RecognizeBatch()` API uses an exact-shape `[N,3,H,W]`
detector batch and same-width `[N,3,48,W]` recognizer crop batch; it never
rescales or pads unrelated page sizes merely to enlarge `N`. `det_batch_size`,
`rec_batch_size`, `rec_batch_width_bucket`, and `image_batch_parallelism`
remain the bounded controls, with `ppocr_batch_smoke` checking every batched
result against serial OCR before timing it.

On the local AVX-512 / Radeon 780M host, eight identical `en.ppm` tiny-model
pages (`det_batch_size=8`, `rec_batch_size=8`, one page worker) returned the
same 16 decoded results as serial execution. The measured CPU serial/batch
pair was **329.520 / 201.876 ms (1.632x)**; hybrid was **382.402 / 237.445 ms
(1.610x)**. A five-size small-model check (`16x16`, English, low contrast,
`3000x80`, CJK; batch sizes 4) likewise preserved all 9 results: CPU
**520.065 / 512.529 ms (1.015x)** and hybrid **438.718 / 427.016 ms
(1.027x)**. The mixed-size figures are intentionally not presented as a
universal throughput guarantee.

The refreshed Radeon Vulkan primitive suite passed numerical validation for
every existing batch primitive. Its strict full-boundary probes again admitted
the heavier fused work where it won (affine+Swish **0.16926 ms GPU vs 0.31296
ms CPU**; depthwise+Swish **0.36218 vs 0.66808 ms**; depthwise+HardSwish
**0.36482 vs 0.37636 ms**) and retained CPU for transfer-bound `1x1` Conv,
ordinary/transpose Conv, resize+add, and GEMM. This is intentional dynamic
selection: `gpu_only` remains explicitly unavailable until the complete
detector, recognizer, transformer, and CTC graph are device-resident.

### 2026-08-12: three-model CPU/GPU batch baseline refresh

The current pure-C++ build was rebuilt and rechecked on the complete
tiny/small/medium model set. The SIMD kernel suite passed under normal
AVX-512 dispatch and again with `PPOCR_DISABLE_AVX512=1`, exercising the AVX2
fallback. The Vulkan smoke suite passed on the Radeon 780M, including batched
binary/broadcast/affine/pointwise/depthwise/ordinary-convolution/transpose/
resize-add/GEMM primitives. In that run the full-boundary admission policy
selected Vulkan for depthwise (**0.35698 vs 0.36624 ms**), depthwise+Swish
(**0.35930 vs 0.59468 ms**), depthwise+HardSwish (**0.34864 vs 0.41902 ms**),
and affine+Swish (**0.17778 vs 0.34676 ms**); all transfer-bound primitives
stayed on CPU. The decision is shape-local and dynamic, so it lowers CPU work
without forcing a slower device boundary.

Decoded-text parity against ONNX Runtime passed **4/4** diverse inputs for
each model (tiny, small, medium): `16x16`, English, low contrast, and an
ultra-wide `3000x80` strip. A five-size serial-versus-batch gate for medium
also preserved all 9 results in CPU and hybrid modes. Its measured CPU pair
was **1257.378 / 1292.344 ms** and hybrid was **1266.158 / 1279.121 ms**;
this heterogeneous batch did not improve latency, so it is recorded as a
correctness/capacity check rather than a throughput claim.

For an `en.ppm` single-page steady-state snapshot (two warmups, five runs,
16 kernel workers), current CPU means were tiny **38.755 ms**, small
**73.192 ms**, and medium **208.209 ms**. Hybrid means were **34.575 ms**,
**75.141 ms**, and **238.014 ms** respectively. The short shared-host sample
therefore supports hybrid for tiny when the admitted GPU segments help, while
CPU remains the sensible choice for small/medium on this UMA device. These
numbers are host-specific and do not change the explicit `gpu_only` contract.

### 2026-08-12: hybrid admission re-audit

The next GPU-admission pass measured the current single-primitive boundaries
again instead of lowering thresholds blindly. On this Radeon 780M, batched
depthwise+Swish remained a useful GPU segment (**0.32756 ms GPU vs 0.57274 ms
CPU**), and the depthwise+HardSwish sample also crossed the no-slower rule
(**0.32540 vs 0.36794 ms**). Pointwise Conv, ordinary Conv, transpose Conv,
resize/add, and GEMM samples remained transfer/synchronization-bound, so they
continue on CPU. This preserves the hybrid contract: GPU is selected whenever
the complete measured boundary is equal or faster, not merely because a
shader exists.

The current source also retains conservative size guards before invoking an
admission microbenchmark. A short experiment removing them caused extra
small-shape probes and worse end-to-end tiny behavior on this UMA device, so
the guards were retained. Fresh post-audit checks passed kernel SIMD smoke,
the full Vulkan smoke suite, three-model four-size ONNX Runtime decoded-text
parity (**12/12**), five-size serial/batch output identity, and a medium
hybrid two-cycle memory soak. The latter began at **494,878,720 bytes** after
warm-up and ended **9,105,408** and **11,042,816 bytes below** baseline.

### 2026-08-12: GPU batch revalidation

GPU execution remains batch-aware: equal-width recognition crops are one NCHW
Vulkan dispatch (the shader maps crop `N` to its Y dimension), while the CPU
page scheduler bounds concurrent detector/recognizer workspaces. The pointwise
Conv shader stages compact immutable `[M,C]` weights in workgroup memory and
handles normal, ReLU, Swish, Sigmoid, and residual-Swish forms without an
intermediate activation. Hybrid admission still measures the entire H2D +
dispatch + D2H path for each shape and uses GPU only when the validated result
is no slower than the CPU SIMD counterpart.

### 2026-08-12: exact-shape detector batching

`RecognizeBatch()` now also coalesces pages whose normal PP-OCR detector
resize dimensions are exactly equal. This is a real `[N,3,H,W]` detector
batch: no document is padded, and each result is independently DB
postprocessed from its own probability-map slice. `Options::det_batch_size`
(default `4`) bounds the detector activation frontier; the smoke harness
accepts `PPOCR_DET_BATCH_SIZE` for A/B runs. CPU batch kernels therefore see
useful detector `N` work in addition to the existing same-width recognizer
crop batches.

The current hybrid path deliberately keeps this new detector batching at
`N=1`. Its Vulkan coverage is still partial and synchronous, so applying an
unproven large detector GPU segment would be transfer/admission-bound rather
than an optimization. CPU-only detector batches are available now; hybrid
continues to batch recognizer crops and only admits validated no-slower GPU
segments. This preserves the explicit `gpu_only` contract: full GPU OCR is
not claimed until detector, recognizer, transformer, and CTC stay
device-resident.

On this AVX-512 / Radeon 780M host, tiny PP-OCRv6 over eight identical
`en.ppm` pages (recognizer batch `8`, one worker) produced exactly the same
16 OCR results as serial inference. The steady-state smoke measurement was
**323.281 ms serial / 195.744 ms batch (1.652x)** with `PPOCR_DET_BATCH_SIZE=8`,
versus **330.019 / 247.684 ms (1.332x)** with detector batching forced to one.
The hybrid check preserved output identity at **311.225 / 243.242 ms
(1.279x)**; as designed, it retained singleton detector dispatches. A varied
five-page CPU run (`16x16`, English, low contrast, `3000x80`, and dense
`1920x1080`) stayed correct but measured only **1.019x**, so equal-shape
coalescing is a throughput tool for compatible page sets閳ユ攺ot a universal
mixed-document latency guarantee. Tiny, small, and medium each also retained
their four-image C++/ONNX Runtime decoded-text parity gate after the change.

### 2026-08-12: FPN resize-plus-add write fusion

The detector loader now recognizes the exported FPN sequence `Resize(nearest,
asymmetric floor, 2x) -> Add(equal-shape residual)` and replaces it with a
single `FusedNearestResizeAdd` node. Its NCHW implementation writes each
replicated source value directly into the final residual-sum allocation. This
removes the enlarged temporary feature map, its allocation, and its second
full read/write traversal. The fusion is deliberately limited to the exact
2x detector geometry; all other ONNX Resize combinations retain the generic
executor.

The local profile confirms all three recursive FPN additions are fused
(`Resize.0_add`, `Resize.1_add`, `Resize.2_add`). The post-change five-run
comparison on `en.ppm` (2 warm-ups, 16 benchmark threads) measured:

| Model | C++ hybrid mean | ORT CPU mean | C++ latency advantage |
|---|---:|---:|---:|
| tiny | 32.104 ms | 148.088 ms | 78.32% |
| small | 66.087 ms | 237.150 ms | 72.13% |
| medium | 259.850 ms | 454.815 ms | 42.87% |

This is one host's paired measurement rather than a general hardware claim.
Decoded-text parity against ONNX Runtime passed for each model on four varied
inputs (`16x16`, normal English, low contrast, and a `3000x80` strip). A
medium two-cycle varied-shape soak (`16x16`, English, low contrast, strip,
and `1920x1080` UI) ended at **-77,824 bytes** versus its warmed 391,249,920
byte private-memory baseline; this is allocator reuse evidence, not a claim
of zero memory use or a leak proof.

### 2026-08-12: runtime-SIMD FPN resize-add kernel

`FusedNearestResizeAdd` now calls a dedicated kernel rather than using scalar
replication inside the graph executor. The new kernel performs the 2x
replication and both residual-row additions in the same final stores, with
runtime AVX-512, AVX2, ARM NEON, and scalar fallback implementations. It is
covered by odd-width and batched low-level smoke cases, and
`PPOCR_DISABLE_RESIZE2X_ADD_SIMD=1` provides a narrowly scoped scalar A/B
path without disabling the other inference SIMD kernels.

On the local AVX-512 machine, a dense `1920x1080` tiny page (123 detected
crops, 2 warm-ups / 5 timed runs) measured **264.174 ms** with this SIMD
path versus **265.651 ms** through the scalar resize-add fallback (about
**0.56%** faster). This small but repeatable bandwidth-path improvement is
reported separately because whole-page timing remains sensitive to crop-count
and host load; correctness was also checked with AVX-512 disabled.

The refreshed local Radeon 780M smoke run passed all binary, broadcast,
affine, pointwise, residual, odd-plane, batched, and parameterized
`Conv+HardSigmoid` graph primitives. Its measured admission samples were:
affine+Swish **0.16466 ms GPU / 0.29544 ms CPU** (admitted), standalone `1x1`
Conv **0.14536 / 0.01952 ms**, and residual `1x1` Conv+Swish **0.18884 /
0.10648 ms** (both correctly retained on CPU). A tiny `en.ppm` pipeline check
(1 warm-up, 8 runs) measured **30.122 ms CPU** and **29.521 ms hybrid**; output
stayed identical. This small 2.0% difference is host-noise-sensitive and is
not presented as a general GPU speed claim.

### 2026-08-12: three-model, diverse-size regression

The CPU executor now has a dedicated `1x1 Conv -> HardSwish` path for the
canonical detector squeeze-excitation sequence. It writes convolution output
directly to the final activation allocation, then applies the existing
runtime-selected AVX-512/AVX2/NEON/scalar HardSwish kernel in place. This
preserves the exact `Conv -> HardSigmoid -> Mul` FP32 result while avoiding the
generic graph's temporary Conv activation. The Vulkan pointwise shader also
now covers parameterized `Conv+HardSigmoid`; its alpha/beta are passed as raw
FP32 push constants and remain behind the same complete-transfer admission
rule.

After the change, C++ versus ONNX Runtime decoded-text parity passed **7/7**
tiny samples covering English, CJK, blank, `16x16`, `3000x80`, low-contrast,
and mixed-content inputs. Small and medium also passed the ONNX Runtime text
gate on `en.ppm`. Kernel and Radeon 780M Vulkan smoke suites passed, including
the batched odd-plane pointwise and new HardSigmoid case.

On `en.ppm` (2 warm-ups, 10 timed runs, AVX-512 host), the measured
end-to-end comparison was:

| Model | C++ CPU mean | ONNX Runtime CPU mean | C++ advantage |
|---|---:|---:|---:|
| tiny | 29.159 ms | 121.267 ms | 4.16x faster |
| small | 61.785 ms | 184.410 ms | 2.98x faster |
| medium | 190.529 ms | 360.038 ms | 1.89x faster |

These measurements use the repository's ORT benchmark with the same image and
CPU execution provider; they are host-specific, but demonstrate a consistent
gain for all three PP-OCRv6 model sizes. A multi-size page-batch regression
(`16x16`, `3000x80`, and dense `1920x1080`) preserved output identity for
tiny/small/medium. Its throughput was 1.035x for tiny and 0.982x/0.975x for
small/medium on this mixed workload, so batching remains a bounded-capacity
feature rather than a universal latency claim. A medium two-cycle mixed-size
memory soak ended only **+4,345,856 bytes** above its 374,845,440-byte warmed
baseline.

### 2026-08-12: CTC LayerNorm activation reuse

`RunCtcTop1()` is the recognizer path used by public OCR calls. It now reuses
the input allocation for a fused transformer `LayerNorm` when that input has
one remaining consumer. LayerNorm first completes the mean/variance reductions
for a row and only then writes that row, so the source/destination alias is
safe and preserves the existing FP32 expression. This removes eligible
`[N,T,C]` temporary activations in the small and medium recognizers without
changing model scope or introducing a runtime dependency.

The feature has an A/B escape hatch, `PPOCR_DISABLE_CTC_LAYERNORM_INPLACE=1`,
for deployment validation. On the local AVX-512 host it produced modest
steady-state benefit on the short `en.ppm` workload (medium 225.182 ms enabled
versus 227.161 ms disabled, 2 warm-ups / 10 runs); actual benefit is expected
to be more useful for activation pressure on dense crop batches. The full
post-change regression passed kernel SIMD smoke, Radeon 780M Vulkan smoke,
the seven-image tiny ONNX Runtime text gate, and small/medium ONNX Runtime
text parity on `en.ppm`. The small/medium three-size batch gate also preserved
all 121/124 decoded results. `gpu_only` remains explicitly unavailable until
the entire detector, recognizer, transformer, and CTC pipeline is
device-resident; hybrid continues to admit each batch-shaped Vulkan segment
only when end-to-end transfer, dispatch, and readback are no slower than CPU.

### 2026-08-12: hybrid batch verification harness

`ppocr_batch_smoke` now accepts `PPOCR_BACKEND=cpu|hybrid|gpu` and the
recognizer batch controls `PPOCR_REC_BATCH_SIZE` and
`PPOCR_REC_PARALLELISM`. This makes the same serial-versus-page-batch
bit-for-bit output gate usable for the GPU-enabled hybrid path, instead of
testing only CPU scheduling. `gpu` retains the library's explicit failure
contract while the full PP-OCRv6 graph is not Vulkan-resident.

On the local AVX-512 / Radeon 780M host, tiny PP-OCRv6 with four varied pages
(`en`, `line_en`, `mixed`, `zh`), recognizer batch size 4 and one recognizer
worker produced eight identical OCR results in both serial and page-batched
modes. The measured scheduler results were:

| Backend | Serial | Page batch (parallelism 2) | Speedup |
|---|---:|---:|---:|
| CPU | 120.904 ms | 81.793 ms | 1.478x |
| Hybrid | 147.315 ms | 104.593 ms | 1.408x |

The hybrid result is intentionally reported as measured, not as a GPU win:
on this UMA GPU the available Vulkan segments are partial and transfer-bound
outside the admitted affine+Swish shape. The key correctness result is that
batch output remains identical while all runtime GPU selection stays
per-shape, batched, and no-slower-than-CPU. Reproduce with:

```powershell
$env:PPOCR_BACKEND='hybrid'
$env:PPOCR_REC_BATCH_SIZE='4'
$env:PPOCR_REC_PARALLELISM='1'
.\build\ppocr_batch_smoke.exe DET.onnx REC.onnx dict.txt 2 `
  .\build\regression_ppm\en.ppm .\build\regression_ppm\line_en.ppm `
  .\build\regression_ppm\mixed.ppm .\build\regression_ppm\zh.ppm
```

### Batch scheduling and current GPU evidence

`OCR::RecognizeBatch(const std::vector<Image>&)` is now the public page-batch
API. It preserves image/result order and exact per-image OCR output, while each
page keeps the existing same-width recognition-crop batching. Page images are
scheduled independently rather than padded into a single detector tensor: this
avoids wasted detector pixels and preserves PP-OCRv6's dynamic resize
semantics. `Options::image_batch_parallelism` bounds live page workspaces
(default `1`); when it is above one, the configured recognizer-worker budget
is divided among concurrently running pages so image batching does not multiply
the CPU thread count or activation frontier. `ppocr_batch_smoke` checks every
nested batch result against serial `Recognize()` before reporting timing.

On the local AVX-512 / Radeon 780M host, after warm-up, the tiny model over
four mixed PPM pages (`en`, `mixed`, `line_en`, `line_zh`) produced the same
seven OCR results in serial and batch modes. A short 2026-08-11 CPU snapshot
with page parallelism `2` measured **81.981 ms serial** and **53.183 ms batched**
(**1.541x** throughput). This is a scheduler/host-specific result, not a
promise for every page mix; the bounded default remains one page to minimize
peak memory. Reproduce it with:

```powershell
.\build\ppocr_batch_smoke.exe DET.onnx REC.onnx dict.txt 2 `
  .\build\regression_ppm\en.ppm .\build\regression_ppm\mixed.ppm `
  .\build\regression_ppm\line_en.ppm .\build\regression_ppm\line_zh.ppm
```

The Vulkan path already batches same-width NCHW crop tensors in one dispatch
and holds model-constant compact RHS/BatchNorm coefficients in persistent
buffers. The post-change Radeon 780M smoke run passed scalar, odd-sized,
four-stage chain, four-crop, broadcast, affine, and fused affine-Swish checks.
Its measured full-transfer admission samples were binary **0.29160 vs 0.01368
ms**, four-stage chain **0.16206 vs 0.02984 ms**, four-crop chain **0.14928 vs
0.02766 ms**, and channel-affine **0.13928 vs 0.01326 ms** (GPU vs CPU), so
hybrid correctly rejected those transfer-bound segments. The batched
affine-Swish segment measured **0.18272 ms GPU vs 0.30170 ms CPU** and was
therefore admitted for that exact shape. This is an isolated, verified GPU
segment; full `gpu_only` OCR remains unavailable until the convolution,
pooling, resize, transformer, and CTC graph is device-resident.
On the Radeon 780M, the latest 65,537-float repeated admission test measured
about **0.119 ms GPU versus 0.013 ms CPU**, so hybrid correctly declines this isolated
elementwise segment rather than increasing latency or CPU work. This is an
honest partial-graph capability contract, not a claim that GPU inference is
already complete.
The same persistent shader now supports a dependent chain of up to four
Add/Sub/Mul/Div operations in one dispatch, reusing device-resident operands
without intermediate host transfers. Its smoke test validates a 65,537-float
four-stage chain and applies the same full H2D/dispatch/D2H comparison. On this
Radeon 780M it measured about **0.124 ms GPU versus 0.030 ms CPU**, so hybrid again
correctly declines the GPU segment. This supplies a reusable fused-elementwise
building block for future PP-OCR graph segments without misrepresenting it as
complete GPU inference.
The Vulkan path also implements compact suffix-broadcast channel gates such as
`[N,C,H,W] op [N,C,1,1]`: the right operand is transferred once per batch
shape instead of being materialized to `N*C*H*W`. Runs whose four lanes stay
inside a channel span use `vec4`; only span boundaries use the scalar tail.
Its own full-transfer admission benchmark validates every output and retains
CPU SIMD unless the compact-GPU path wins. On this Radeon 780M, a four-item
8,192-float, 64-value-span `Mul+Add` gate measured **0.143 ms GPU versus
0.013 ms CPU**, so the policy correctly declined it. This is nevertheless
important GPU groundwork: it removes broadcast-expansion memory/traffic and
is connected to both generic and terminal-CTC in-place executor paths.

The batch path now also distinguishes the two valid compact RHS layouts:
dynamic `[N,C,1,1]`, and the much more common learned constant
`[1,C,1,1]`. The latter is now stored once in the persistent Vulkan RHS buffer
and addressed with a zero batch stride in the shader, rather than being
duplicated/uploaded once for every recognition crop. The Vulkan smoke test
executes two different four-crop activations against the same immutable
128-value RHS to verify both batch indexing and cache reuse. On the AMD
Radeon 780M, measured on 2026-08-11 after this change, the full-transfer
four-crop `8,192`-float `Mul+Add` shared-RHS building block was **0.11126 ms
GPU versus 0.00772 ms CPU**, so hybrid still (correctly) selects CPU SIMD.
This is a real batch-memory/traffic reduction, not a claim of end-to-end GPU
OCR acceleration while the surrounding graph remains CPU-resident.
The next batched GPU primitive is the exact inference affine
`x * scale + bias` used by fused BatchNorm. It keeps both `[1,C,1,1]`
coefficient vectors compact, caches immutable scale/bias pairs separately,
and transforms all same-width crops in one dispatch; it is wired into both
normal and terminal-CTC executor paths behind the same full-transfer admission
gate. The refreshed Radeon 780M smoke run (2026-08-11) measured the four-crop
`8,192`-float shared-coefficient affine at **0.10054 ms GPU versus 0.00656 ms
CPU**, so hybrid correctly retains the CPU SIMD affine path on this UMA device.
This establishes a useful batch/residency building block without pretending
that the present partial Vulkan graph makes end-to-end OCR faster.
The same compact four-crop kernel now also has an exact FP32
`BatchNorm affine -> Swish` mode, matching the recognizer's folded
`FusedBatchNormSwish` nodes. It evaluates `x * scale + bias` and its logistic
activation in one Vulkan dispatch, keeps immutable `[1,C,1,1]` scale/bias
vectors cached, and avoids returning to the CPU between the two operations.
It is connected to the hybrid executor through its own per-shape end-to-end
admission check. On the Radeon 780M on 2026-08-11, the four-crop
`8,192`-float shared-coefficient test measured **0.16744 ms GPU versus
0.37652 ms CPU**, so this heavier fused batch segment was admitted to GPU;
the smoke test validates every result against the exact CPU Swish expression.
This is a genuine batched hybrid acceleration, while the surrounding PP-OCR
graph remains CPU-resident and `gpu_only` remains unavailable.

### 2026-08-11: batched pointwise-Conv GPU experiment

The Vulkan executor now also contains a verified FP32 NCHW `1x1` Conv
primitive, with optional fused ReLU, Swish, and Sigmoid. It accepts a batch of equal-width
recognition crops in one dispatch, reads learned `[M,C]` weights and bias once
from persistent compact buffers, and writes to a separate lazily allocated
output buffer. The shader processes four adjacent spatial positions per
invocation when they remain in one output-channel plane; scalar tails preserve
odd widths and channel boundaries. The hybrid executor is wired only for
unit-stride, unpadded, ungrouped `Conv` / `Conv+ReLU` with immutable ONNX
weight+bias inputs. As with existing hybrid nodes, each `(N,C,M,plane,ReLU)`
shape is admitted only after an end-to-end H2D/dispatch/D2H benchmark validates
every FP32 result against the CPU SIMD kernel.

On the local AMD Radeon 780M, the four-crop `C=24, M=40, plane=257` smoke
case passed normal and ReLU numerical checks. Its complete-transfer admission
measurement was **23.715 ms GPU versus 0.026 ms CPU**, so hybrid correctly
rejected this pointwise segment on this UMA driver. The implementation is kept
as a portable batched GPU building block for devices/shapes where it wins; it
does not claim a GPU speedup here and does not change the `gpu_only` contract.

### 2026-08-12: fused GPU Sigmoid gate and refreshed checks

The pointwise Vulkan path now also fuses exact `Conv -> Sigmoid` (shader mode
10). This covers the detector's post-folding pointwise gate form without a CPU
activation pass or an extra activation buffer. Its public low-level API and
hybrid admission key distinguish ReLU, Swish, and Sigmoid; the admission probe
includes complete host upload, dispatch, fence wait, readback, and FP32
comparison with the CPU reference. A shape is selected only when that whole
round trip is no slower than CPU, and `gpu_only` remains unavailable until the
complete detector/recognizer/transformer/CTC graph is device-resident.

On the local AVX-512 / AMD Radeon 780M host, the refreshed Vulkan smoke test
passed the batched, odd-plane (`N=4, C=24, M=40, plane=257`) Conv+Sigmoid
numerical check together with existing binary, affine, Swish, residual, and
shared-memory-tiled pointwise checks. The same run reported:

| Segment admission sample | GPU | CPU | Hybrid selection |
|---|---:|---:|---|
| Batch affine+Swish | 0.15924 ms | 0.29874 ms | GPU |
| Batch `1x1` Conv | 0.16150 ms | 0.02062 ms | CPU |
| Batch `1x1` Conv+Swish | 0.18282 ms | 0.10534 ms | CPU |
| Batch residual `1x1` Conv+Swish | 0.14726 ms | 0.09338 ms | CPU |

These are measured partial-segment results on a UMA GPU, not an end-to-end GPU
claim. A post-change whole-pipeline smoke benchmark on `regression_ppm/en.ppm`
with the tiny model (3 warm-ups, 12 runs) measured CPU **28.584 ms** and
hybrid **27.684 ms** mean. A medium-model check (2 warm-ups, 8 runs) measured
CPU **201.388 ms** and hybrid **206.885 ms**; shared-host variation and partial
coverage mean CPU remains the sensible default for this device. Both modes
preserved OCR output correctness. The low-level AVX-512 kernel regression also
passed normally and with `PPOCR_DISABLE_AVX512=1`, verifying the AVX2 fallback.

Reproduce the verification:

```powershell
cmake --build build --parallel
.\build\ppocr_vulkan_smoke.exe
.\build\ppocr_kernel_smoke.exe
$env:PPOCR_DISABLE_AVX512='1'; .\build\ppocr_kernel_smoke.exe
Remove-Item Env:PPOCR_DISABLE_AVX512
```

### 2026-08-12: diverse-size batch and memory regression

The post-tile regression was widened beyond short English lines. With
recognizer batch size 4 and one recognition worker, the medium model preserved
serial-equivalent OCR across a `16x16` tiny glyph, a `3000x80` wide strip, and
a dense `1920x1080` UI page (124 total results). It measured **5652.199 ms
serial / 5552.878 ms batch** (`1.018x`) and a subsequent two-cycle mixed-size
memory soak used **391,716,864 bytes** after warm-up; cycles ended at
**+6,422,528** and **+184,320 bytes**. This is bounded Windows allocator
retention after the dense page, not a per-shape cache. Small-model CPU and
hybrid checks likewise preserved output parity across `16x16`, `3000x80`,
mixed-language, and dense-page cases. The current GPU graph is still partial,
so page batching is a capacity feature rather than a universal latency win;
the bounded default remains one concurrent page.

The accompanying 1-warmup/7-run `en.ppm` whole-pipeline A/B (same host,
default batch settings) was:

| Model | CPU mean | Hybrid mean | Result |
|---|---:|---:|---|
| tiny | 27.867 ms | 34.334 ms | CPU faster |
| small | 67.981 ms | 79.373 ms | CPU faster |
| medium | 205.998 ms | 214.396 ms | CPU faster |

This outcome is expected for a partial graph with synchronous round-trips;
use `PPOCR_BACKEND=cpu` on this device for current end-to-end throughput. The
six-image mixed-size page-batch regression still produced byte-identical OCR
results versus serial execution and measured **410.192 ms serial**, **373.145
ms batched** at page parallelism 2 (**1.099x**).
For a fuller pipeline A/B on the same shared Windows host (small model,
`ui_dense_1920x1080.ppm`, 119 boxes, 16 CPU workers, recognizer batch 4 /
parallelism 14, one warm-up and three timed runs), CPU measured **1044.384 ms
mean** and hybrid **1081.426 ms mean**. This short noisy sample is recorded as
an end-to-end non-regression check rather than a GPU speedup: the per-shape
admission rule continued to reject GPU segments, and hybrid's small overhead
remains a reason to use `PPOCR_BACKEND=cpu` when the deployment only needs the
current CPU graph.

After the fused Swish GPU path was added, a fresh small-model dense-page A/B
(`ui_dense_1920x1080.ppm`, 119 boxes, batch 4, parallelism 14, 1 warm-up / 3
runs) measured **1170.717 ms hybrid** and **1155.998 ms CPU**. The short run is
intentionally reported as a non-regression observation rather than an
end-to-end GPU speed claim: only eligible BatchNorm-Swish shapes are offloaded,
and scheduling/shape mix can still outweigh an individual accelerated segment.
The per-shape gate continues to preserve correctness and rejects any shape
whose complete transfer/dispatch/readback time loses to CPU.

The CPU fallback for the exact `Sigmoid`, `Swish`, and
`BatchNorm -> Swish` paths is also unrolled into four independent scalar-libm
exponentials. This improves instruction-level parallelism on x86 (including
AVX-512 hosts, where there is still no exact vector `exp` instruction) and
ARM/NEON without adopting an approximate exponential or changing the ONNX
logistic expression. The post-change tiny/small/medium ONNX Runtime text
checks remained **5/5**, **3/3**, and **3/3** respectively.
Fused `BatchNorm -> Swish` now also reuses the source activation when it is at
its final graph use. This removes one recognizer-sized output allocation and
copy on both x86 and ARM/NEON while preserving the affine, exact logistic, and
multiply operation sequence per scalar. It can be A/B tested with
`PPOCR_DISABLE_BN_SWISH_INPLACE=1`. On the shared host, a small-model
three-crop `mixed.ppm` sample was noisy and did not show a reliable latency
win (100.535 ms in-place vs 98.598 ms legacy over 15 runs), whereas medium
measured 278.592 vs 282.793 ms over 10 runs; therefore this is recorded as an
activation-memory/frontier optimization rather than a portable speed claim.

A later experiment to fuse transformer `GEMM -> exact Swish` at row granularity
was A/B tested and intentionally not retained: its benefit was not stable on
small/medium at the end-to-end level. The portable GEMM and exact Swish passes
therefore remain separate, avoiding an unsupported speed claim. This is the
same evidence-first policy used for every hybrid GPU admission.

The same shader now accepts an equal-sized batch in its Vulkan dispatch Y
dimension: independent recognizer-like crops share one command-buffer reset,
submission, completion wait, and H2D/D2H pair instead of paying those costs once per
crop. Each compute invocation handles four contiguous FP32 values (`vec4`) and
keeps only a 1--3 value scalar tail, reducing work-item scheduling overhead on
wide OCR planes. The shader updates the mapped left-hand activation buffer in
place, eliminating the former dedicated output buffer and its activation-sized
copy: this Vulkan primitive now retains two persistent buffers
(activation/result plus compact RHS), rather than three. Persistent mapped
buffers now prefer coherent host-cached memory when the Vulkan driver offers
it (with a portable coherent-memory fallback), grow with 1.5x headroom, and
resize the activation/result independently of the compact RHS. This avoids
needless buffer recreation when recognition width buckets change. Completion uses a submission fence rather
than queue-wide idle, so an individual synchronous mapped readback does not
also wait for unrelated queue work. The batch admission check validates every
item and includes complete batched transfer/dispatch/readback time; hybrid
selects it only when that time is no slower than CPU SIMD. The current Radeon
780M four-crop, 4,099-float, four-stage check measured **0.146 ms GPU versus
0.037 ms CPU** after this batch-path update, so hybrid correctly retained CPU.
This is an implemented
batched Vulkan executor path and building block, not a full GPU OCR claim until
convolution, pooling, resize, normalization, MatMul, and CTC are device-resident.

For repeatable backend A/B measurements, `ppocr_bench` accepts
`PPOCR_BACKEND=cpu|hybrid|gpu` (default: `hybrid`) in addition to
`PPOCR_REC_BATCH_SIZE`, `PPOCR_REC_WIDTH_BUCKET`, and
`PPOCR_REC_PARALLELISM`. Its JSON output records the selected backend. `gpu`
continues to fail explicitly until the full PP-OCRv6 graph is Vulkan-resident;
it never labels a CPU fallback as GPU inference.

The post-optimization Vulkan smoke test on 2026-08-11 passed scalar,
non-workgroup-aligned, 65,537-element, dependent-chain, four-item batch, and
compact NCHW suffix-broadcast batch cases on AMD Radeon 780M Graphics. The
suite now also covers an immutable shared-RHS broadcast batch over two distinct
activations. The broader native regression corpus also
passed **11/11** cases: blank, tiny, wide/tall strips, low-contrast/noisy,
rotated, dense blobs, and 1,920鑴?,080 / 2,560鑴?,440 screenshots. Text parity
against ONNX Runtime passed **5/5** mixed English/Chinese samples. Exact pixel
geometry is intentionally not a strict invariant because equivalent DB contour
rounding can differ by one pixel; recognized text and normal-tolerance
confidence parity are checked.

The CPU convolution path additionally fuses ReLU into the AVX-512/AVX2
2鑴?-valid and 3鑴? convolution stores (both stride-1 and stride-2), which
removes the subsequent full activation read/write pass for detector stems,
the reconstruction head, and the medium detector context head.
`PPOCR_DISABLE_FUSED_CONV_RELU=1` is
available solely for deployment A/B measurement; it retains the former
separate SIMD ReLU pass. On the two-line `en.ppm` workload, a 20-run tiny A/B
was **39.385 ms fused vs 40.599 ms unfused** (about 3.0% lower mean latency).
After the stride-1 extension, a 15/12/12-run A/B measured tiny at **46.692 vs
48.548 ms** (3.8% lower), small at **128.286 vs 136.103 ms** (5.7% lower), and
medium at **312.317 vs 292.898 ms**. The medium result is adverse on this
shared host, so the `PPOCR_DISABLE_FUSED_CONV_RELU` escape hatch remains for
deployment tuning; it is reported rather than presented as a portable gain.
Correctness was rechecked with AVX-512 disabled (AVX2 dispatch), five ORT
text-parity samples, and the 11-case stress corpus.

Adding 2鑴?-valid coverage was remeasured on the same `en.ppm` workload:
15-run tiny was **35.783 vs 37.773 ms** (5.3% lower), medium was **271.887 vs
272.238 ms** (0.1% lower), while small contained a single 738.612-ms scheduling
outlier (median **91.147 vs 94.687 ms**). The median is the useful comparison
for that shared-host run; all raw mean/median/p95 numbers remain available from
`ppocr_bench` JSON for deployment-specific decisions.

The executor now also transfers a dead activation's backing storage through
internal `Reshape`, `Squeeze`, and `Unsqueeze` nodes instead of copying floats
solely to change tensor metadata. It retains the existing last-use and graph
output guards, so aliases never escape into a live consumer or public result.
The terminal-CTC recognizer executor uses the same transfer path, covering the
small/medium transformer reshape boundaries rather than only the generic
executor. ORT text parity passed tiny **5/5** and small/medium **3/3** sampled
English, Chinese, and mixed pages after this change. The expanded 11-image
stress suite also passed. A size-changing memory soak across `en.ppm` and
`ui_dense_1920x1080.ppm` remained bounded: tiny stabilized around 80 MiB
private bytes (at most +3.61 MiB above its post-warmup sample) and medium
stayed below its 308.93 MiB post-warmup sample on the measured cycles; small
remained around 105--112 MiB (+6.34 MiB at most after warmup). Dense-page
native throughput was additionally exercised with 119 small-model crops
(1.422 s mean) and 122 medium-model crops (6.009 s mean), confirming the
optimized recognizer path under varied crop widths and bounded batches.

`PPOCR_PROFILE=1` now additionally emits a separate `ppocr CTC operator
profile` for the recognizer's terminal-CTC executor. This exposes the actual
small/medium transformer costs (rather than only detector `Run()` nodes) while
keeping the release path free of timing/map allocations. On the 123-crop dense
page, tiny-model batch-size tuning measured `rec_batch_size=4` at **323.479
ms**, versus 348.242 ms (8) and 339.535 ms (16); the default remains 4. A
parallelism sweep for that same batch size measured 498.854 ms (4 workers),
392.288 ms (8), 339.808 ms (14), and 329.693 ms (24). The 24-worker result is
only a small host-specific gain with a higher concurrent activation frontier,
so the library retains its more memory-efficient default of 14 workers.

The current transformer kernels add two further low-memory CPU optimizations.
Wide AVX-512/AVX2 GEMM projections now retain four output vectors in registers
across the entire K reduction, eliminating the former output load/store for
every K item; this directly targets the `FusedMatMulBias` vocabulary head.
The repeated LayerNorm `Pow(x,2)` nodes now use a SIMD square kernel and reuse
their dead centered activation in place, avoiding both `powf` and a second
`[N,T,C]` allocation. The latter is exact multiplication, not an approximate
math mode. On the latest 16-worker 20-run paired `en.ppm` measurement, the
current release measured **41.718 ms tiny, 93.439 ms small, and 270.362 ms
medium**, against ONNX Runtime CPUExecutionProvider **144.039, 272.186, and
640.506 ms** respectively. That is **0.290x / 0.343x / 0.422x** C++/ORT
latency (about **71.0% / 65.7% / 57.8% lower** C++ latency) on this shared
host. Exact ORT text parity after these changes passed tiny **5/5** and
small/medium **3/3** English, Chinese, and mixed-image cases.

A post-change changing-size memory soak (`en.ppm` plus the 1,920鑴?,080 dense
page) remained bounded. Tiny's warm baseline was **78,929,920 bytes** and
its largest measured delta was **+1,032,192 bytes**; small's baseline was
**107,143,168 bytes** and its largest delta **+6,766,592 bytes**; medium was
at or below its **284,958,720-byte** warm baseline in both measured cycles.

The five transformer LayerNorm chains in each small/medium recognizer are now
recognized at model load and collapsed from `ReduceMean 閳?Sub 閳?Pow 閳?ReduceMean 閳?Add 閳?Sqrt 閳?Div 閳?Mul 閳?Add` into one affine last-axis kernel.
It creates only the final `[N,T,C]` activation, eliminates centered/squared/
normalized temporary tensors, and keeps the standard `sqrt`, division, gamma,
and beta operation ordering. On the same 16-worker 20-run `en.ppm` protocol,
the resulting C++ measurements were **36.683 ms tiny, 75.827 ms small, and
229.388 ms medium**, while the paired ORT figures remain **144.039, 272.186,
and 640.506 ms**. That is **74.5% / 72.1% / 64.2% lower latency** for the
native path on this host. Post-change text parity passed tiny **5/5** and
small/medium **3/3**. A fresh multi-size soak measured small from a
**109,473,792-byte** warm baseline with a maximum **+4,493,312-byte** delta;
medium began at **276,164,608 bytes** with a maximum **+929,792-byte** delta.

`MatMul + bias + Sigmoid + Mul` gates in the small and medium transformer MLPs
are also fused into a single bias-initialized MatMul followed by in-place Swish;
each model matches this graph pattern twice. It removes the intermediate bias
and sigmoid activations without changing FP32 operation order. Text parity
after that change passed tiny **5/5** and small/medium **3/3** against ONNX
Runtime. A fresh CPU-only 16-worker sanity run (5 warmups / 20 runs, subject
to documented Windows scheduling variation) measured **43.778 ms tiny,
97.592 ms small, and 277.404 ms medium** on `en.ppm`; the established paired
ORT baseline above remains the authoritative cross-engine comparison.

The fused MLP path is now additionally specialized for its actual PP-OCRv6
rank-2 constant projection: it derives the flattened row count directly and
avoids generic batch-shape/stride bookkeeping before invoking GEMM, then
applies Swish in the same destination. Generic broadcasted `MatMul` retains
the portable implementation, but its batch strides are now computed once per
node instead of allocating them once per batch item. The latest validation
covered all three models across **16 PPM inputs**: tiny and small completed all
16 in one run, while medium completed all 16 in two timeout-bounded eight-image
runs. The corpus spans 16x16, 80x3000, 3000x80, noisy/low-contrast, rotated,
dense, blank, Chinese/English/mixed, and 1920x1080 / 2560x1440 screenshot
inputs. Exact ORT text parity was rechecked as tiny **5/5** and medium **3/3**
after the specialisation; small's existing **3/3** exact gate remains passing.

The AVX-512 `1x1 Conv + residual Add` path now has a real eight-output
register tile rather than issuing two four-output kernels. Each 16-float input
vector is loaded once and contributes to eight independent output channels;
the residual is added only after each channel reduction, retaining the ONNX
`Conv` then `Add` operation order. On the same 16-worker, 5-warmup/20-run
medium `en.ppm` A/B, the enabled tile measured **296.941 ms** (median 295.073)
versus **317.217 ms** (median 317.510) with
`PPOCR_DISABLE_AVX512_POINTWISE8=1`: a **6.4% mean** reduction on this host.
The current post-change CPU sanity sweep measured **42.518 ms tiny, 86.810 ms
small, and 296.941 ms medium**; shared-host variance means the established
paired C++/ORT table remains the authoritative engine comparison. Tiny 5/5
and medium 3/3 ORT text parity were repeated after the kernel change; the
medium three-size memory soak (16x16, 3000x80, dense 1920x1080) started at
**330,235,904 bytes** and ended one cycle at **+4,177,920 bytes**. Vulkan's
scalar, odd-size, chain, batch, and compact-broadcast smoke cases also passed.

Recognizer attention transpose now has exact rank-4 specialisations for the
two PP-OCRv6 permutations `[0,2,1,3]` and `[0,1,3,2]`. The former moves its
contiguous final feature vector with `memcpy`; both avoid the generic
per-float four-axis divide/modulo index decoder. After the change, ORT text
parity passed tiny **5/5**, small **3/3**, and medium **3/3**. On the current
16-worker 5-warmup/20-run CPU samples, tiny/small/medium measured **42.771 /
87.300 / 261.648 ms** on `en.ppm`. The current Vulkan smoke run also passed;
the Radeon 780M admission samples remained GPU-slower end to end and hybrid
therefore retained CPU SIMD rather than claiming an unsupported speedup.

Attention Q/K/V splitting now also has a safe contiguous `Slice` fast path:
when ONNX Slice selects an axis-0 unit-stride range while preserving every
remaining axis, it transfers the complete `[axis-0 row]` span with one
`memcpy` rather than doing per-value stride division/modulo. This exactly
matches the stacked Q/K/V slices used by the small and medium recognizers;
all non-contiguous or non-unit-step layouts retain the general ONNX Slice
implementation. The post-change exact ORT gates passed tiny **5/5**, small
**3/3**, and medium **3/3**. A wider eight-case small-model corpus was also
run; six cases passed (blank, English, Chinese, mixed, line, and noisy), while
the deliberately difficult dense-screen and rotated-text samples are currently
recorded as known OCR-output divergences from ORT rather than excluded or
misreported as a passing parity gate.

The recognizer's remaining final-head layout exchange `[N,T,C] -> [N,C,T]`
now also uses a direct three-axis loop instead of generic shape/stride index
decoding. Together with the rank-4 attention paths, this covers every fixed
transpose permutation used by the shipped tiny/small/medium recognizers while
retaining the generic implementation for other ONNX graphs. The post-change
parity gates again passed tiny **5/5**, small **3/3**, and medium **3/3**.
The medium short benchmark remained shared-host variable (a fresh 20-run
sample measured 302.714 ms), so no additional end-to-end speed claim is made
from that isolated run; the change is retained for lower overhead on the
repeated transpose-heavy recognizer paths.

The latest backend A/B sample on the two-line tiny workload (`en.ppm`, 3
warmups / 15 runs) measured **41.533 ms hybrid** versus **42.553 ms CPU**.
This small 2.4% difference is within normal shared-host variability: the
Radeon admission measurements above declined all tested segments, so it must
not be interpreted as a standalone GPU OCR speedup. On the 123-crop dense
page (2 warmups / 7 runs), hybrid measured **311.501 ms** and CPU **314.929
ms**; both paths preserve exact CPU inference for the parts of PP-OCRv6 not
yet resident on Vulkan.

After the LayerNorm/transformer update, the denser 123-crop 1,920鑴?,080 workload
was repeated for 3 warmups / 10 runs: **299.313 ms hybrid** (median 297.708)
and **293.864 ms CPU** (median 292.125). The Radeon 780M's independently
measured admissions still rejected the individual Vulkan elementwise segments
(for example the compact broadcast batch was 0.106 ms GPU versus 0.010 ms
CPU), so this close whole-pipeline comparison is recorded as shared-host
variance rather than claimed GPU acceleration.

After the Vulkan batch-buffer/fence update, the same 123-crop dense page was
rechecked for 3 warmups / 10 runs: **346.120 ms hybrid** (median 342.037) and
**347.319 ms CPU** (median 345.431). This near tie is shared-host variance,
not GPU acceleration: all current per-shape admissions still rejected the
Radeon 780M elementwise segments. The smoke suite passed scalar, odd-length,
fused-chain, compact broadcast, and four-crop batch cases; its current
end-to-end admission samples were 65,537-float binary **0.256 vs 0.028 ms**,
four-stage chain **0.169 vs 0.032 ms**, four-crop chain **0.146 vs 0.037 ms**,
and compact broadcast **0.150 vs 0.016 ms** (GPU vs CPU). `gpu_only` was also
rechecked and continues to fail explicitly because the full Vulkan OCR graph
has not yet been implemented.

After the in-place mapped-buffer update, Vulkan smoke was rerun on 2026-08-11
and passed scalar, odd-length, fused-chain, four-crop batch, and compact
broadcast batch outputs on AMD Radeon 780M Graphics. Current full-transfer
admission samples remained transfer-bound: binary **0.333 vs 0.034 ms**,
four-stage chain **0.250 vs 0.047 ms**, four-crop chain **0.133 vs 0.031 ms**,
and compact broadcast **0.161 vs 0.015 ms** (GPU vs CPU). Accordingly hybrid
still executes those isolated segments with CPU SIMD. The saved mapped-buffer
memory is real, but it is not represented as a whole-OCR GPU speedup.

The fused pointwise-convolution channel-bias path now uses the existing
runtime-dispatched scalar-broadcast kernel per NCHW plane. This removes its
scalar inner loop while preserving the exact `Conv` then `Add` order, with
AVX-512, AVX2, NEON, and portable scalar coverage selected dynamically. The
follow-up exact ORT gates passed tiny **5/5**, small **3/3**, and medium
**3/3**. A post-change 16-worker 5-warmup/20-run CPU sanity sample measured
**41.587 / 84.744 / 259.606 ms** for tiny/small/medium on `en.ppm`; Windows
scheduling varies enough that the paired C++/ORT table above remains the
authoritative cross-engine claim. A small dynamic-size memory soak across
16鑴?6, 3000鑴?0, and dense 1920鑴?080 inputs started at **110,268,416 bytes**;
two cycles ended at **-2,564,096** and **+2,109,440 bytes** from that baseline,
respectively, with no monotonic retained-shape growth.

The latest exact-mode CTC confidence scan now issues four independent
scalar-libm exponentials before adding them in the original lane order. This
preserves the 6,906-class Softmax confidence calculation and CTC output while
allowing x86 (including AVX-512-capable systems) and ARM cores to overlap exp
latency. Build plus ONNX Runtime text gates passed tiny **5/5**, small **3/3**
and medium **3/3** after the change. A fresh 16-worker, 5-warmup/20-run CPU
sanity pass on `en.ppm` measured **36.458 / 70.745 / 218.498 ms** for
tiny/small/medium. The same revision's diverse-size CPU sweep recorded:

| Model | `en.ppm` (2 boxes) | `wide_strip_3000x80.ppm` | `ui_dense_1920x1080.ppm` |
|---|---:|---:|---:|
| tiny | 33.555 ms | 23.269 ms | 278.795 ms (123 boxes) |
| small | 74.727 ms | 57.801 ms | 1136.849 ms (119 boxes) |
| medium | 221.817 ms | 150.859 ms | 4626.259 ms (122 boxes) |

Those short varied-size samples are intentionally recorded as local CPU
capacity data, not substituted for the repeated paired C++/ORT table. The
post-change small mixed-size two-cycle memory soak (16x16, 3000x80, and
1920x1080 dense UI) measured **-12,288 bytes** then **+5,222,400 bytes** from
a 109,170,688-byte baseline, showing no monotonically growing allocation per
input shape. Vulkan smoke also passed on AMD Radeon 780M Graphics; full
transfer admission remained CPU-faster (binary **0.13716 vs 0.01282 ms**,
four-stage batch **0.10178 vs 0.02728 ms**, GPU vs CPU), so hybrid correctly
continued to avoid increasing latency or CPU work with an unprofitable GPU
offload.

For AVX-512 x86 systems, the detector's hot stride-2 3x3 convolution now
forms its sixteen every-other-pixel samples from two contiguous row loads and
an AVX-512 lane permute, rather than issuing a gather for each 3x3 tap. The
packed-load implementation remains dynamically switchable with
`PPOCR_DISABLE_AVX512_STRIDE2_PACKED=1`, preserving the prior gather kernel
for any deployment where its microarchitecture wins. On this host's medium
`en.ppm` 16-worker 5-warmup/20-run A/B, packed loads measured **219.768 ms**
(median 216.588) versus **274.781 ms** (median 229.537) for gathers. The mean
is scheduler-sensitive, but both median and mean favor the packed path. Its
full exact ORT text gates passed tiny **5/5**, small **3/3**, medium **3/3**;
a medium mixed-size memory cycle (16x16, 3000x80, dense 1920x1080) ended
**98,304 bytes below** a 277,999,616-byte baseline. The Vulkan smoke suite
also remained passing; its current full-transfer admissions still correctly
select CPU for this Radeon 780M, so this CPU optimization never changes the
GPU-only or hybrid correctness contract.

An AVX-512 eight-output-channel 3x3 stride-one detector kernel shares every
interior input vector across eight output reductions while retaining scalar
border handling and the exact per-channel reduction order. A refreshed
24-run, 2-warmup CPU A/B on the current host shows the current restricted
default predicate is beneficial for all three `en.ppm` models: tiny
**32.010 -> 31.166 ms** (1.027x), small **66.480 -> 65.099 ms** (1.021x),
and medium **207.772 -> 203.876 ms** (1.019x), four-output -> tile-8.
`PPOCR_DISABLE_AVX512_CONV3X3_TILE8=1` remains the deployment fallback for
machines whose AVX-512 frequency characteristics differ. The stricter shape
gate still routes smaller layers, odd channel tails, AVX2, NEON, and scalar
targets to their existing proven paths.

The adjacent AVX-512 eight-output `1x1` projection tile was also refreshed as
a negative-control A/B, rather than broadening its predicate speculatively.
With the current `192x192` gate, four-output -> eight-output measured tiny
**32.097 -> 34.343 ms** (regression), small **70.746 -> 66.848 ms** (win),
and medium **216.021 -> 214.452 ms** (small win), using the same 2-warmup,
24-run CPU procedure. Consequently the shape-local `192x192` default and
`PPOCR_DISABLE_AVX512_POINTWISE8=1` fallback remain unchanged: a single global
threshold cannot improve every tier on this client CPU. This is deliberately
recorded rather than claiming a universal pointwise gain.

The detector FPN's common nearest-neighbour 2x resize now writes four source
pixels as eight direct replicated stores before vertically copying the row.
This keeps the exact NCHW output layout while removing per-pixel
`std::fill_n` setup in every 2x FPN plane; uncommon integer resize factors
retain the existing general replication path. A fresh default medium
16-worker 5-warmup/20-run `en.ppm` sample measured **209.972 ms** (median
210.745 ms). Exact ORT text regression again passed tiny **5/5**, small
**3/3**, medium **3/3**, and Vulkan smoke stayed passing. A two-cycle tiny
mixed-size soak across 16x16, 3000x80 and 2560x1440 inputs stayed bounded at
**+1,150,976** then **+2,654,208 bytes** relative to its 82,276,352-byte
post-warmup baseline; this represents Windows heap retention, not a
per-inference activation leak.

Recognition batch construction no longer allocates and copies a temporary
`vector<CropBounds>` for every batch. Same-width buckets now retain contiguous
crop bounds and result indices once, and `RecInputBatch` consumes a direct
span. This removes hundreds of small allocations/copies on dense pages while
preserving crop order, width bucketing, bounded batch size, and concurrent
recognizer behavior. The medium 122-box dense 1920x1080 smoke workload
completed correctly after this change (a short 2-warmup/5-run local sample
was **5541.268 ms**, subject to the documented scheduler/cache variability).
Exact ORT text parity remained tiny **5/5**, small **3/3**, medium **3/3**;
Vulkan scalar/chain/batch/broadcast smoke passed. A medium mixed-size
16x16/3000x80/1920x1080 memory cycle completed without a failure; its
post-warmup private-byte result is retained as capacity data rather than
claimed as a leak-free steady-state proof because the Windows allocator kept
10,149,888 bytes after this deliberately large dense workload.

The Vulkan binary runtime now recognizes immutable ONNX initializer operands.
When hybrid dispatches an eligible elementwise node, its RHS remains in the
persistent mapped Vulkan buffer across later activations of the same model,
avoiding a repeated host copy while retaining a separate activation/result
buffer. Dynamic RHS tensors always copy, and the existing full end-to-end
admission policy is unchanged: a cached constant does not qualify GPU unless
the whole H2D/dispatch/D2H segment is no slower than CPU. The smoke suite now
checks two distinct activations against a cached 65,537-float immutable RHS;
it passed on AMD Radeon 780M Graphics along with scalar, chain, batch and
broadcast cases. Current admissions remain CPU-faster on this UMA host, so
hybrid correctly preserves CPU SIMD rather than claiming a GPU OCR speedup.
The default CPU executor's tiny **5/5**, small **3/3**, and medium **3/3**
ORT text gates were rerun after the backend API change.

### Batched Vulkan residual pointwise block

The Vulkan backend now has a verified batched `1x1 Conv + residual Add`
primitive, with a `Conv + Add + ReLU` variant. It maps equal-width recognition
crops to Vulkan's Y dimension, keeps learned `[M,C]` weights and bias cached
when they are ONNX initializers, and uploads the residual into a separate
read-only buffer so the shader never aliases an input with its output. This
is also wired into the existing fused CPU graph nodes in `hybrid` mode, while
the shape-specific admission test includes both live activation uploads,
parameter transfer, dispatch, readback, and an FP32 CPU comparison.

On 2026-08-11, the AMD Radeon 780M smoke test validated normal and ReLU
residual pointwise results for four NCHW batches, including a 257-element
non-vector-aligned spatial plane. Its full-transfer admission measurement for
the `N=4, C=24, M=40, plane=257` `Conv+Add+ReLU` case was **19.1844 ms GPU**
versus **0.0326 ms CPU**, so hybrid correctly rejected the GPU segment. The
normal pointwise case was likewise **19.1564 ms GPU** versus **0.03072 ms
CPU**. These figures are deliberately recorded as a negative end-to-end
result: the new GPU kernel is numerically covered and batch-capable, but
standalone host-visible uploads/readback make it inappropriate on this UMA
device. `gpu_only` remains explicitly unavailable until the complete OCR
graph can execute device-resident without CPU fallbacks.

After this change, the tiny five-image C++/ONNX Runtime text regression again
passed **5/5**. The six-image mixed-size page-batch smoke (151 detected text
regions, page parallelism two) completed in **381.767 ms** versus **408.840
ms** serial, a **1.071x** scheduler speedup on the local shared host.

The residual-ReLU AVX-512 eight-output entry point was also exercised on the
same host. Its real eight-live-accumulator version passed the five-image text
gate, but did not demonstrate a stable end-to-end win: `mixed.ppm` small was
**86.242 ms** versus **82.700 ms** with the default four-output tile, and the
medium results varied between runs. It therefore continues to delegate to the
proven four-output residual-ReLU tile instead of becoming an unvalidated
default. This keeps AVX-512 dynamic and safe while avoiding a register-pressure
regression on both tiny and small workloads.

The current medium mixed-size memory soak (`16x16`, `3000x80`, `80x3000`, and
the 151-region `1920x1080` UI page; two cycles) established a post-warm-up
private-byte baseline of **347,013,120 bytes**. The next cycles were
**+303,104 bytes** and **+3,276,800 bytes**. This bounded allocator-capacity
movement is recorded as a Windows high-water observation rather than a general
leak proof; importantly it did not grow once per dynamic shape or per crop
batch.

### 2026-08-11: GPU residual-vector and non-ReLU batch fusion follow-up

The residual pointwise shader now vectorizes its common four-contiguous-spatial
lane case as well as the non-residual pointwise shader.  It performs
`1x1 Conv + residual Add (+ ReLU)` in registers and writes one final NCHW
result, retaining a scalar tail only at plane boundaries and odd widths.  The
graph loader also recognizes the strict dynamic `1x1 Conv -> equal-shape Add`
form without a following ReLU as `FusedPointwiseConvAdd`.  This matters for
the medium recognizer: a CPU profile of `mixed.ppm` observed fused non-ReLU
shortcut nodes such as `Conv.9_add`, `Conv.20_add`, `Conv.50_add`, and
`Conv.31_add`, so they now avoid a materialized Conv result plus a separate
Add pass on both CPU and eligible hybrid paths.  Initializer/broadcast Adds
remain excluded, preserving ONNX bias semantics.

The rebuilt Vulkan smoke suite passed all binary, broadcast, affine, normal
pointwise, residual pointwise, and residual-ReLU numerical checks on AMD
Radeon 780M Graphics.  Its latest complete-transfer measurements were
**21.0106 ms GPU vs 0.02642 ms CPU** for `N=4,C=24,M=40,plane=257` pointwise
Conv and **14.2844 ms GPU vs 0.03048 ms CPU** for residual+ReLU; hybrid
therefore rejected both exactly as designed.  The separate tiny five-image
C++/ORT text gate passed **5/5**, and the six-page mixed-size batch smoke
produced identical nested results in **81.021 ms** versus **122.164 ms**
serial (**1.508x**).  A short `mixed.ppm` end-to-end check measured **34.379
ms CPU** versus **40.314 ms hybrid** (one warm-up, three runs), so current
deployment guidance remains CPU for this UMA GPU; these GPU additions are
correct, batched building blocks rather than an unsupported full-GPU claim.

### 2026-08-11: Vulkan mapped-memory policy revalidation

The persistent Vulkan buffers now explicitly score host-coherent memory types
for this synchronous hybrid runtime: `HOST_CACHED` coherent memory is selected
first, then host-visible device-local coherent memory, then a portable coherent
fallback. This is not merely a theoretical ordering. An A/B on the Radeon 780M
showed that preferring host-visible `DEVICE_LOCAL` for every mapped buffer made
the complete binary segment about **10.65 ms GPU vs 0.0195 ms CPU**, while the
cached mapped policy restored it to **0.137 ms GPU vs 0.015 ms CPU**. The
device-local mapping was therefore rejected; shader-side device locality does
not compensate for slower CPU copies in an H2D/dispatch/D2H hybrid segment.

With the restored policy, the refreshed smoke suite passed every numerical
case. Its four-crop affine-Swish segment was **0.13832 ms GPU vs 0.29722 ms
CPU**, so hybrid selects Vulkan for that shape; the pointwise and residual
pointwise probes remained transfer-bound (**20.6638 vs 0.0269 ms**, and
**14.3158 vs 0.03158 ms**, respectively) and are correctly retained on CPU.
This is the required behavior for `hybrid`: prefer GPU only when the measured
full segment is no slower, while avoiding a silent fallback in `gpu_only`.

Post-change correctness evidence includes small and medium C++/ONNX Runtime
text parity on `en.ppm` (**1/1** each) and a medium mixed-size memory soak over
`16x16`, `mixed`, and the `1920x1080` 151-region UI image. Its post-warm-up
private-byte baseline was **361,832,448** and the next cycle was
**-7,499,776 bytes** from that baseline, consistent with a bounded allocator
high-water rather than retained dynamic workspaces. A six-page tiny batch
regression still returned byte-identical nested results; the shared-host run
measured **126.196 ms serial / 108.076 ms batch (1.168x)**. Timing varies with
contention, so this documents correctness and a measured throughput win rather
than a portable promise.

### 2026-08-11: batched GPU Conv+Swish fusion

### 2026-08-12: tiled batched Vulkan pointwise convolution

The batched Vulkan `1x1` convolution shader now has a workgroup-tiled path
for `C <= 1024`. One 256-thread workgroup owns four output channels and a
256-pixel spatial tile, cooperatively stages the four immutable `[C]` weight
rows in shared memory, then produces four contiguous FP32 values per lane.
This removes the former per-`vec4` weight streaming in the common NCHW
pointwise case. The same path covers Conv, Conv+ReLU, Conv+Swish, and the
equal-shaped residual variants; odd plane tails still use an exact scalar
write and wider channel counts retain the established generic shader path.

This is a real GPU-kernel and batch-throughput improvement, not an invented
end-to-end GPU win. On the local AMD Radeon 780M, the verified four-crop
`N=4,C=24,M=40,plane=257` smoke measurement improved from the earlier
multi-millisecond pointwise dispatches to **0.16412 ms GPU** for Conv and
**0.15202 ms GPU** for Conv+Add+Swish. CPU SIMD still measured **0.02170 ms**
and **0.09334 ms**, respectively, so the complete H2D/dispatch/D2H admission
rule correctly retains CPU on this UMA host. The smoke suite validates all
normal, ReLU, Swish, residual, and non-vector-aligned outputs before timing.

The rebuilt tiny four-page scheduler check (`en`, `line_en`, `mixed`, `zh`;
batch size 4, recognizer parallelism 1, page parallelism 2) remained output
identical after the shader change. This run measured **128.114 ms serial /
88.105 ms batch (1.454x)** on CPU and **125.542 ms / 77.657 ms (1.617x)**
in hybrid mode. These short shared-host samples are scheduler evidence, not a
replacement for the paired ONNX Runtime table above. `gpu_only` remains
explicitly unavailable until the complete PP-OCRv6 graph is device-resident.

For a post-change whole-pipeline sanity A/B on `en.ppm` (16 CPU workers,
batch size 4, recognizer parallelism 1, three warm-ups and ten timed runs),
hybrid measured **34.387 / 72.977 / 216.534 ms** for tiny/small/medium.
The separately sampled CPU tiny run was **36.125 ms**; due shared-host noise
and partial-graph selection these are not substituted for the longer paired
CPU-versus-ORT results. The relevant GPU proof is the verified tiled primitive
and its conservative per-shape full-transfer admission, not an unsupported
claim that all three models now execute fully on the Radeon GPU.

The Vulkan pointwise kernel now also supports the graph-fused PP-OCR pattern
`1x1 Conv -> Sigmoid -> Mul` as an exact FP32 `1x1 Conv + Swish` operation.
Four equal-width NCHW crops share one submission; learned `[M,C]` weights and
`[M]` bias remain compact and can be retained in the persistent parameter
buffers. This removes the CPU-side full-output Swish traversal when a shape is
admitted to Vulkan, without changing the portable AVX-512/AVX2/NEON fallback.

The smoke test verifies the fused output at every element for a four-crop,
non-vector-aligned `N=4, C=24, M=40, plane=257` workload. On the local Radeon
780M its full synchronous H2D/dispatch/D2H measurement was **12.2472 ms GPU
versus 0.13918 ms CPU**, so `hybrid` correctly retains CPU SIMD for that shape.
This is nevertheless a material batch-capable GPU graph building block: a
device/shape is allowed to select it only after this complete measurement and
numerical validation; it is not represented as an end-to-end GPU OCR win on
the present UMA system. The expanded tiny C++/ONNX Runtime text gate passed
**5/5** (`en`, English line, Chinese line, mixed, Chinese page), and the
six-page batch regression preserved identical OCR results at **123.546 ms
serial / 86.991 ms batch (1.420x)** on this run.

### 2026-08-11: shortcut Swish fusion and broader regression pass

Small and medium recognizers contain an inverted-residual suffix
`BatchNorm -> Swish -> Add(shortcut)`. The loader now recognizes this after
the first fusion sweep and emits one `FusedBatchNormSwishAdd` node. Its CPU
kernel produces the affine, exact logistic Swish and equal-shaped residual Add
in one traversal, reusing the dying BatchNorm input allocation. This removes
the intermediate Swish feature map and the separate Add pass. It is protected
by `PPOCR_DISABLE_BN_SWISH_ADD_FUSION=1` for A/B work; a short medium
`mixed.ppm` CPU check (one warm-up / three runs) measured **242.378 ms** fused
versus **260.514 ms** unfused (**7.0% lower latency**), with expected shared
host variance.

Vulkan now exposes the matching batched `channel-affine + Swish + Add`
primitive. Its smoke test validates every output of four `8192`-float NCHW
crops. On the Radeon 780M, complete transfer timing was **0.14988 ms GPU vs
0.14072 ms CPU**, so hybrid correctly chose CPU for that exact case. The graph
path has the same cached no-slower admission rule: it may use Vulkan only when
the full H2D/dispatch/D2H measurement and FP32 validation win; otherwise it
uses the CPU fused path and does not add GPU overhead.

Current post-change evidence: tiny C++/ORT text parity remained **5/5** over
English, Chinese and mixed samples; small and medium each passed an independent
ORT text check on `en.ppm` (**1/1** each). A six-page varied-content tiny batch
regression remained result-identical at **126.926 ms serial / 96.686 ms batch
(1.313x)**. A medium memory soak spanning `16x16`, mixed text, and a dense
`1920x1080` page finished one cycle **7,614,464 bytes below** its
376,975,360-byte post-warm-up baseline, consistent with bounded workspace reuse.

### 2026-08-12: batched Vulkan HardSwish coverage

The graph-fused detector pattern `1x1 Conv -> HardSigmoid -> Mul` now reaches
the Vulkan pointwise kernel as one exact `Conv+HardSwish` dispatch. The shader
receives the ONNX `alpha` and `beta` as raw FP32 push constants and writes
`x * clamp(alpha*x + beta, 0, 1)` directly to the final NCHW output. It uses
the same four-crop Y-dimension batch mapping, shared-weight tile, odd-plane
tail handling, persistent parameter cache, and complete H2D/dispatch/D2H
admission policy as the other pointwise variants. CPU retains its
AVX-512/AVX2/NEON/scalar exact fallback.

The post-change Radeon 780M smoke suite validated every value of an odd-plane
`N=4, C=24, M=40, plane=257` batch. The full synchronous admission sample was
**0.15912 ms GPU / 0.02794 ms CPU**, so this UMA host correctly keeps that
segment on CPU; no end-to-end GPU OCR speedup is claimed. A seven-image tiny
CPU-versus-hybrid output gate (`en`, mixed, CJK, tiny, wide, low-contrast,
blank) passed **7/7** with identical decoded output. With recognizer batch size
4, recognizer parallelism 1, and page parallelism 2, the seven-image hybrid
batch gate preserved output identity and measured **337.565 ms serial /
234.153 ms page-batch (1.442x)**. This is scheduler throughput evidence on
the local machine, not a general GPU performance promise.

### 2026-08-12: three-size CPU/hybrid and memory revalidation

The current build was retested after the Vulkan HardSwish integration with
the official tiny, small, and medium model pairs. The seven-image C++/ONNX
Runtime text gate passed **7/7 for every model** (English, mixed Latin,
CJK, `16x16`, `3000x80`, low-contrast, and blank). The broader tiny stress
corpus also passed **11/11**, including rotated text, dense blobs, and
`1920x1080`/`2560x1440` screenshots.

On `en.ppm` (2 warm-ups, 10 timed runs, 16 CPU workers, recognizer batch 4,
one recognizer worker), the local CPU/hybrid recheck was:

| Model | CPU mean | Hybrid mean | CPU / Hybrid decoded output |
|---|---:|---:|---|
| tiny | 35.164 ms | 34.684 ms | identical |
| small | 71.442 ms | 71.286 ms | identical |
| medium | 205.222 ms | 225.598 ms | identical |

Hybrid is therefore not described as a universal win: each Vulkan segment is
still admitted independently only when its verified complete transfer,
dispatch, and readback time is no slower than the CPU SIMD equivalent. The
medium mixed-size memory soak (`16x16`, mixed text, dense `1920x1080`; two
cycles) used 367,849,472 private bytes after warm-up and ended at
+4,378,624 bytes, consistent with bounded allocator high-water behavior.

### 2026-08-11: batched residual Conv+Swish GPU fusion

The Vulkan batch kernel now also supports the full graph-proven recognizer
suffix `1x1 Conv -> Add(shortcut) -> Sigmoid -> Mul` as mode 9:
`1x1 Conv + residual Add + exact Swish`. Equal-width OCR crops share its Y
dispatch dimension; the learned `[M,C]` weights and `[M]` bias remain compact
and cacheable, and the shortcut is read once before the final device write.
The CPU fallback adds `PointwiseConvAddSwish`, keeping the Conv+shortcut in
the existing AVX-512/AVX2/NEON fused path and overwriting that single output
allocation with exact Swish. Set
`PPOCR_DISABLE_POINTWISE_ADD_SWISH_FUSION=1` to restore the unfused ONNX
sequence for an A/B comparison.

The extended Vulkan smoke test validates every value of an odd-plane
four-crop `N=4,C=24,M=40,plane=257` batch. On the local Radeon 780M, its full
H2D/dispatch/D2H comparison measured **12.3933 ms GPU vs 0.09822 ms CPU**,
so hybrid correctly rejected it. The currently profiled small PP-OCRv6 export
does not emit this exact four-node suffix, so no end-to-end OCR speed claim is
made for the new matcher yet; it is retained as a verified batch-capable
building block for compatible PP-OCRv6 exports, not an unsupported GPU speed
claim on the present UMA host.

### Tiny / small / medium comparison

The same complete two-line OCR pipeline was also measured with the official
three PP-OCRv6 model sizes on this 16-thread AVX-512-capable host.  Model load
is excluded from steady-state latency. The native and ONNX Runtime commands
were run separately with the same PPM input and matching dictionaries. The
following exact-Erf run is the current repeated baseline; `PPOCR_APPROX_GELU`
was unset for every native measurement.

| Model | Native runs / warmup | Pure C++ mean | ORT mean | Native / ORT | Native FPS | ORT FPS |
|---|---:|---:|---:|---:|---:|---:|
| tiny | 20 / 5 | 33.322 ms | 120.106 ms | 0.277x | 30.010 | 8.326 |
| small | 20 / 5 | 83.639 ms | 184.190 ms | 0.454x | 11.956 | 5.429 |
| medium | 20 / 5 | 281.236 ms | 428.584 ms | 0.656x | 3.556 | 2.333 |

This current default-exact run is a same-host comparison with matching model
files and image. It shows lower C++ latency for tiny, small, and medium
(72.3%, 54.6%, and 34.4% respectively). The commands were run as paired
engine measurements, but Windows scheduling still affects individual samples;
the complete JSON output should be retained when refreshing capacity numbers.

The earlier approximate-GELU deployment experiment is retained below as a
separate, opt-in result rather than being conflated with default ONNX-equivalent
execution:

| Model | Native runs / warmup | Pure C++ mean | ORT mean | Native / ORT | Native FPS | ORT FPS |
|---|---:|---:|---:|---:|---:|---:|
| tiny | 10 / 3 | 34.125 ms | 137.535 ms | 0.248x | 29.304 | 7.271 |
| small | 8 / 3 | 95.049 ms | 226.928 ms | 0.419x | 10.521 | 4.407 |
| medium | 8 / 3 | 257.848 ms | 457.041 ms | 0.564x | 3.878 | 2.188 |

All values are from the same 2026-08-11 host and PPM input. The native run
used the persistent 16-worker executor; ONNX Runtime used
`CPUExecutionProvider` with the matching 16-thread budget. The refreshed
measurements show lower mean latency for all three model sizes on this host.
The table below uses the validated optional approximate-GELU deployment setting;
the default exact-Erf paired comparison is documented above.
The opt-in approximation passed the strict 7-image text corpus and the 11-image
size/diversity stress corpus; retain the exact default for applications that
require strict numerical ONNX equivalence.
The specialized stride-2 3x3 gather path remains material for medium:
disabling it measured 2646.179 ms versus 1923.504 ms when enabled with one
requested worker. These are local measurements, not a portable performance
guarantee.

All three model pairs produce the expected two recognized lines in the native
smoke test. The strict 7-image text-parity and 11-image size/diversity stress
gates below use tiny because their known-text expectations correspond to its
dictionary; they exercise input dimensions from 16x16 to 2560x1440.
The latest default-exact verification also forced the dynamic AVX2 fallback
with `PPOCR_DISABLE_AVX512=1`: tiny/small/medium completed at 43.170/113.518/
408.928 ms in a short 8-run sweep. This confirms that AVX-512 remains a
runtime-selected acceleration, not a binary deployment requirement; ARM/NEON
and scalar paths retain the same portable graph implementation.

### Batched constant-weight MatMul fusion

Recognizer attention projections commonly have a batched activation and one
rank-2 immutable weight tensor. The executor now flattens those independent
batch dimensions into one tall GEMM call, avoiding repeated per-batch GEMM
dispatch and allowing the SIMD/NEON GEMM to use its normal row scheduling over
the whole recognition batch. No weights are repacked or duplicated, and every
output row keeps its original increasing-`K` FP32 accumulation order. This is
enabled by default on x86/AVX-512, x86/AVX2, ARM/NEON, and scalar builds;
`PPOCR_DISABLE_MATMUL_BATCH_FOLD=1` provides an A/B fallback.

On the local 16-worker AVX-512 host, exact-GELU `mixed.ppm` measurements with
three recognized crops, batch size four, recognizer parallelism one, three
warmups and fifteen timed runs showed the direct batch benefit for small:
**137.925 ms mean** with the fold versus **195.572 ms** with the fallback
(29.5% lower latency). A separate default scheduler check (batch four,
parallelism fourteen, 3 warmups / 12 runs) measured **41.663 ms tiny**,
**93.915 ms small**, and **340.519 ms medium** on the same input. These
samples are host-specific and the medium workload remains dominated by
convolution, but they confirm that all three model sizes retain the same
correct batched path. Exact ONNX Runtime text parity remained tiny **5/5**,
small **3/3**, and medium **3/3** after the change.
The same fallback path now fuses equal-shape `1x1 Conv -> Add` residual
projections with an AVX2 four-output register tile rather than materializing
the Conv result before a separate Add. A fresh forced-AVX2 3-warmup/10-run
sanity sweep measured tiny/small/medium at 42.446/122.677/434.793 ms on the
shared host; these are coverage and stability samples rather than a paired
ORT comparison. The strict seven-image text gate passed 7/7 with AVX-512
disabled. ARM/NEON has matching four-output fused residual code; it is selected
only when the target compiler exposes NEON, otherwise scalar remains valid.
For AVX-512, large 1x1 projections now use an eight-output register tile
(with four-output/tail handling retained for smaller shapes). It reuses each
loaded input vector across eight output channels and preserves each output
channel's reduction order. The exact-GELU text gate passed 7/7 and the
11-image size/diversity gate passed after this change; the default exact
three-model table above is the associated repeated benchmark.
A 30-run A/B on the same 16-worker host selected this default for the larger
models: small measured 106.047 ms with the eight-output tile versus 109.533 ms
with `PPOCR_DISABLE_AVX512_POINTWISE8=1`; medium measured 301.179 ms versus
313.123 ms. Individual Windows samples remain scheduling-sensitive, but both
the median and mean favoured the eight-output implementation in that repeated
comparison.
The same eight-output technique is implemented for the already fused
`1x1 Conv+ReLU` path, including its exact scalar tail and runtime ISA guards.
It passes the strict text corpus when enabled, but repeated small/medium
end-to-end A/B samples were mixed (and the 30-run medium sample favoured the
default four-output path: 257.914 ms versus 268.169 ms). It is therefore kept
behind `PPOCR_ENABLE_AVX512_POINTWISE_RELU8=1`, rather than silently trading
stable default latency for a workload-specific result.

### Post-fusion comparison refresh

The latest post-fusion same-host refresh (exact Erf-GELU, 16 requested workers,
5 warmups and 20 measured runs per engine) is recorded below. It includes the
new equal-shape `1x1 Conv -> Add` fusion; operator profiling confirmed fused
residual projections in the medium graph (for example `Conv.9_add`,
`Conv.12_add`, `Conv.20_add`, `Conv.50_add`, and `Conv.53_add`). As with the
earlier table, these are sequential paired measurements on a shared Windows
machine, so they document the current build rather than a portable guarantee.

| Model | Pure C++ mean | ORT mean | C++ / ORT | Pure C++ FPS | ORT FPS |
|---|---:|---:|---:|---:|---:|
| tiny | 43.072 ms | 182.025 ms | 0.237x | 23.217 | 5.494 |
| small | 109.535 ms | 244.420 ms | 0.448x | 9.130 | 4.091 |
| medium | 359.697 ms | 642.622 ms | 0.560x | 2.780 | 1.556 |

This refresh measured native latency lower by 76.3%, 55.2%, and 44.0% for
tiny, small, and medium respectively. The observed C++ ranges were
40.202--48.375 ms, 99.140--127.691 ms, and 284.395--396.259 ms; ORT also
showed large host-scheduling variance, especially medium (427.880--1285.338
ms). Keep the original repeated table above for historical comparison and
rerun the paired procedure on the deployment CPU before capacity planning.

The subsequent gate-fusion validation found 13/13, 13/13, and 5/5 fused
HardSigmoid gates in tiny, small, and medium profile runs respectively. Default
and forced-AVX2 strict text parity both passed 7/7, while the 11-image stress
set still passed 11/11. A short shared-host 3-warmup/10-run sanity sweep was
43.159 ms (tiny), 100.075 ms (small), and 416.331 ms (medium); the wide medium
p95 range reflects host scheduling, so these values are deliberately not
presented as a new ONNX Runtime comparison.

The executor now additionally treats a last-use standalone `HardSigmoid` as
an in-place operation. This applies the same exact AVX-512/AVX2/NEON SIMD gate
without allocating a second activation tensor; it is especially relevant to
dynamic image sizes where keeping the graph frontier small lowers transient
memory. The current strict text and 11-image stress checks passed after this
lifetime optimization.
The detector reconstruction head now folds its terminal `ConvTranspose(2x2,
stride 2) -> Add([1,C,1,1])` pairs into the transposed-convolution bias during
model load. This removes both final feature-map Add traversals for tiny, small,
and medium (confirmed as `ConvTranspose.0_bias` and `ConvTranspose.2_bias` in
the medium operator profile) while retaining exact output and all ISA paths.
The strict seven-image comparison and 11-image dimension/diversity stress
suite remained fully passing after the change.

The recognizer's direct `Conv -> Add([1,C,1,1]) -> ReLU` exports are now folded
at load time into the existing Conv+ReLU kernels. This adds the previously
missing no-Identity form of channel-bias folding, so small/medium stem
projections avoid a broadcast Add pass and its transient result. The same
matcher also recognizes canonical `Conv -> HardSigmoid -> Mul` gates and maps
them to the existing exact AVX-512/AVX2/NEON HardSwish kernel when encountered.
The default and forced-AVX2 tiny text-parity checks both passed 5/5 images, and
the 11-image 16x16-to-2560x1440 stress suite passed 11/11 after the change.

### Current optimization validation and comparison refresh

The current build adds the post-Conv Swish graph fusion described above. The
official medium model profiled here does not contain a matching
`Conv -> Sigmoid -> Mul` sequence after affine folding, so this generic fusion
does not contribute to the following current-model timing. The strict tiny
text-parity suite completed 5/5 images against ONNX Runtime after the change.
The benchmark below was then run on the same shared Windows host with
`PPOCR_BENCH_THREADS=16`, AVX-512 enabled dynamically, exact-Erf GELU, five
warmups and 20 measured iterations. It is recorded here as a reproducible
current-build comparison, not a portable capacity guarantee.

| Model | Pure C++ mean | ORT mean | C++ / ORT | Pure C++ FPS | ORT FPS |
|---|---:|---:|---:|---:|---:|
| tiny | 40.159 ms | 140.930 ms | 0.285x | 24.901 | 7.096 |
| small | 95.946 ms | 234.128 ms | 0.410x | 10.422 | 4.271 |
| medium | 342.556 ms | 599.235 ms | 0.572x | 2.919 | 1.669 |

For this run, native C++ latency was 71.5%, 59.0%, and 42.8% lower than ONNX
Runtime CPUExecutionProvider for tiny, small, and medium. Native throughput
was correspondingly 251.0%, 144.0%, and 74.9% higher. The native/ORT
median/p95 pairs were 39.217/44.732 vs. 142.425/199.114 ms (tiny),
94.667/103.429 vs. 234.956/276.820 ms (small), and 316.130/451.931 vs.
576.425/767.443 ms (medium). The shared Windows host is scheduling-sensitive,
so retain the ranges and rerun this paired procedure on a deployment CPU before
capacity planning. The existing tiny/small/medium repeated exact table remains
the longer-run model-size baseline.
### Dense-text stress result

The small-image result above is not representative of a screen with hundreds
of detected text regions. The native path groups equally sized crops into
bounded batches and schedules up to fourteen independent batches concurrently;
each batch retains its output order and uses an isolated execution workspace.
When multiple batches concurrently reach a CPU-parallel operator, one uses the
persistent worker set while contenders execute their independent channel split
locally. This prevents shared-pool serialization and nested-worker contention.
For the PP-OCR recognizer's terminal CTC head it also reduces logits directly
to argmax plus selected-character probabilities, avoiding an otherwise unused
`[batch,time,6906]` Softmax tensor.
Last-use elementwise activations (GELU, BatchNorm+GELU, ReLU, h-swish and
scale/shift) are updated in-place, eliminating transient activation copies. The
BatchNorm+GELU path now evaluates the exact-Erf GELU in the same pass as its
affine transform, removing a further full activation read/write in the default
exact mode. In the explicitly enabled approximate-GELU deployment mode, the
same affine result routes through AVX-512/AVX2 scale-shift plus vector GELU;
the corpus gates above validate that optional path.
Recognizer `Conv -> BatchNorm` inference pairs are folded into immutable
convolution weights and biases during model loading, removing the BatchNorm
activation pass without changing the deployed C++ runtime dependencies.
The detector FPN `2x2`, stride-2 transposed-convolution blocks have dedicated
AVX2 and AVX-512 implementations selected through the existing runtime ISA
dispatch. They vectorize independent input pixels while keeping the same
output/input-channel accumulation order; scalar and ARM builds retain the
portable implementation. In a direct dense-page operator profile, the two
blocks totalled 3.135 ms with AVX versus 3.597 ms scalar (about 12.8% for
those kernels).
The neighbouring detector reconstruction `2x2` valid convolutions now also
have dedicated AVX-512 and AVX2 kernels. They stream the four contiguous input
rows required by each output vector and avoid generic padding/interior checks;
ARM and scalar builds retain the portable kernel. On the current host this
changed the complete two-line small model from 110.364 ms to 98.112 ms and the
medium model from 352.690 ms to 338.791 ms in the same short-run configuration
(about 11.1% and 3.9% respectively), while dense tiny recognition measured
243.949 ms for 123 boxes.
The larger stride-one `3x3` detector layers use an AVX-512 four-output-channel
kernel as well. Each input vector is loaded once and accumulated into four
independent channel outputs, retaining the original channel/kernel accumulation
order. On the medium profile this reduced `Conv.121` from 26.809 ms to 5.910 ms
and `Conv.3` from 20.759 ms to 12.379 ms; the complete short-run medium OCR
measurement improved from 338.791 ms to 291.049 ms. AVX2, NEON, and scalar
paths remain available through runtime ISA dispatch.
The same four-output `3x3` algorithm is now implemented for AVX2 as well. An
explicit `PPOCR_DISABLE_AVX512=1` run exercised that fallback on the present
machine: medium completed in 404.166 ms and the strict tiny text corpus passed
7/7, confirming that advanced instructions remain dynamically optional rather
than a deployment requirement. ARM/NEON retains its portable vector path.
The scheduler now divides these fused `3x3` layers by four-channel groups,
instead of splitting a group between CPU workers. This preserves input-vector
reuse even for channel-parallel medium layers and safely sends only an incomplete
last group to the scalar tail. The resulting AVX-512 medium run measured
279.329 ms (3.580 FPS); strict text and the 11-image dimension/diversity corpus
both remained fully passing.
The same AVX-512 four-output strategy now covers the medium detector's square
stride-one `5x5` and `7x7` context layers. It cut the profiled `Conv.111`
7x7 from 8.472 ms to 3.898 ms and `Conv.114` 5x5 from 3.973 ms to 1.938 ms;
the complete medium result improved from 279.329 ms to 257.848 ms (3.878 FPS).
Unsupported ISAs and non-square/asymmetric kernels continue through the
existing AVX2/NEON/scalar paths.
Depthwise dispatch now routes square stride-one `7x7` and `9x9` kernels to the
existing AVX-512/AVX2 vector kernel too. This covers medium `Conv.64` (256
channels, 9x9): its local operator profile fell from 8.080 ms to 4.845 ms.
The native benchmark's current medium distribution remains sensitive to shared
host scheduling, so the paired end-to-end table is retained as the comparable
model-size result rather than replacing it with an unpaired one-off sample.
For `1x1 Conv -> ReLU` sequences, the AVX-512 path now applies the clamp before
storing each register-tiled output vector. This removes the separate activation
read/write for the fused detector projections while leaving AVX2, NEON, and
scalar execution on the existing safe Conv-then-ReLU path. The strict text and
11-image dimension/diversity gates passed after the change. On this shared
benchmark host the short medium samples remained scheduler-noisy, so no new
end-to-end speed claim is made without a paired repeated run.
The default exact-Erf GELU path is also parallelized across independent NCHW
planes through the persistent executor. BatchNorm+GELU now precomputes its
per-channel affine coefficients once and submits plane-local exact evaluation
without allocating another activation. On medium profiling this changed the
13 fused GELU calls from 26.743 ms to 7.297 ms while retaining default ONNX
Erf semantics; the strict text and 11-image stress gates passed with
`PPOCR_APPROX_GELU` unset. The optional approximate mode remains available for
deployment-specific validation, not as a correctness requirement.
The recognizer terminal CTC Top-1 reduction now parallelizes only across
independent batch sequences. Each sequence retains its own blank/repeated-token
state, while dense-page batches can distribute vocabulary scans and the selected
character confidence softmax over the persistent worker set. Exact decoded-text
and the 11-image dimension/diversity gates passed in default exact-GELU mode;
the shared-host dense benchmark remains variable, so its paired table remains
the authoritative capacity-planning reference.
CTC's 6,906-way per-step ArgMax also uses dynamically selected AVX-512 or AVX2
vector reductions. It explicitly scans the non-vector-width tail before
locating the first winning class, preserving the scalar tie rule and ensuring
the final vocabulary entries (including the space class) remain observable.
Both default AVX-512 and forced `PPOCR_DISABLE_AVX512=1` AVX2 runs passed the
strict 7-image text corpus; the current exact-GELU dense 123-box run measured
345.415 ms (median 343.977 ms, p95 359.279 ms), subject to the documented
shared-host scheduling variation.
AVX-512 four-output fusion now also covers stride-one asymmetric `1x3/1x5/1x7`
and `3x1/5x1/7x1` detector convolutions. It vectorizes the contiguous spatial
axis, preserves scalar border accumulation, and assigns four-channel groups to
workers so input loads are reused. Medium `Conv.112` (7x1) fell from a recent
3.363 ms profile to 1.211 ms. Default exact-GELU strict-text and 11-image
dimension/diversity gates remained passing; standalone medium timing is still
reported with the documented shared-host variance rather than as a new paired
ORT claim.
The DB connected-component postprocessor represents threshold and visited state
in one byte per probability-map pixel (`0` background, `1` pending, `2` visited),
instead of two full byte maps. This halves that postprocessor workspace while
leaving thresholding, traversal order, scores, boxes, and reading order unchanged.
The detector terminal `Sigmoid` is also executed in-place whenever its input
has no remaining consumers. It reuses the final DB-logit allocation as the
probability map, eliminating a peak activation allocation and copy while
preserving the exact scalar sigmoid expression.
Detector FPN nearest-neighbour integer upscales are implemented as direct
NCHW row replication, and recognizer inverse-Transpose pairs plus Conv channel
bias broadcasts are removed at model load. These changes eliminate dynamic
activation copies without relaxing the exact-GELU accuracy path.
The executor also prunes original constants made unreachable by load-time
Conv/BatchNorm folding. This applies to tiny, small, and medium without
changing runtime graph inputs. A fresh two-cycle mixed-size medium soak
(16x16, 3000x80, noisy scene and 1920x1080 UI page) used a 146.94 MiB
post-warmup baseline; the cycles were 147.21 and 148.18 MiB (+0.27 and
+1.24 MiB). The variation is Windows heap retention rather than monotonic
per-shape growth; longer soak runs should be used for release qualification.
The same mixed-size medium sequence in default exact-GELU mode used a 147.68
MiB post-warmup baseline; two cycles ended at 146.48 MiB and 152.16 MiB
(-1.20 / +4.48 MiB). This is bounded allocator retention rather than a
per-shape activation cache; use longer production soak runs for qualification.
A fresh four-cycle medium run after the pointwise-tile update used a 149.641
MiB post-warmup baseline and ended at 146.504 MiB (-3.137 MiB); its largest
cycle was only 2.022 MiB above baseline. The mixed sequence covered 16x16,
3000x80, low-contrast, and 1920x1080 dense-page inputs, again showing bounded
Windows allocator retention rather than persistent dynamic-shape growth.
The AVX2/AVX-512 direct-convolution path now also covers stride-1 7x7 and
asymmetric 3/5/7x1 or 1x3/5/7 detector kernels, while preserving the same
output/input-channel/kernel accumulation order; ARM and scalar paths retain
the portable implementation.
The dominant NCHW `1x1` convolution kernel also now computes four output
channels per shared SIMD input load (AVX-512, AVX2, and NEON implementations),
reducing hot-path input bandwidth while preserving each channel's accumulation
order.
The detector DB-head `2x2`, stride-1 `SAME_UPPER` max pool is likewise mapped
to a boundary-safe AVX-512/AVX2/NEON kernel, removing generic window and bounds
reconstruction from every output pixel.
The following repeatable stress measurement records the present result on
`build/ui_dense_1920x1080.ppm` (about 123--124 text regions):

| Engine | Warmup | Measured runs | Mean latency | Throughput |
|---|---:|---:|---:|---:|
| Pure C++ PP-OCRv6 | 4 | 10 | 233.805 ms | 4.277 FPS |
| ONNX Runtime 1.28 CPUExecutionProvider | 4 | 10 | 929.357 ms | 1.076 FPS |

The table uses one paired `compare.ps1` run with the persistent executor and
validated approximate-GELU setting. C++ is **74.8% lower latency** (0.252x) and
**297.5% higher throughput** in this specific run. It replaces the previous
serial-recognition baseline of 2680.808 ms, a **11.47x** native speedup.
A repeated parameter
sweep after the copy-elimination changes selected the current default of
`rec_batch_size = 4` and
`rec_parallelism = 14` for this 16-logical-CPU host; applications can tune
these options for their deployment CPU. Short dense runs can vary
materially with CPU scheduling, so use the command below and more runs on the
deployment target before capacity planning:

`Options::rec_batch_width_bucket` (or benchmark environment variable
`PPOCR_REC_WIDTH_BUCKET`) can additionally pack nearby natural crop widths
into one zero-right-padded batch; each crop keeps its own aspect-ratio resize.
The default remains `1`: a local 123-crop dense-page sweep did not demonstrate
a stable CPU benefit from padded work, so exact-width batching remains the
lower-memory default. Wider buckets are available for deployment-specific GPU
or batch-density tuning.

```powershell
powershell -ExecutionPolicy Bypass -File .\bench\compare.ps1 `
  -Image .\build\ui_dense_1920x1080.ppm -Runs 10 -Warmup 4 -Threads 16
```

The captured result is C++ 233.805 ms (median 232.980 ms, p95 244.485 ms) and
ONNX Runtime 929.357 ms (median 930.224 ms, p95 1098.989 ms). Keep repeated
paired measurement when refreshing the table, because dense-page latency can
vary with host scheduling.

The run used four warmups, 10 measured runs, and matching 16-thread CPU budgets.
Use longer repeated measurements on the deployment CPU before capacity planning;
dense-page latency also depends strongly on the detected crop mix.


### Expanded stress corpus

`bench/stress_regression.py` executes the native C++ pipeline over 11 deterministic
local stress images without adding a runtime dependency. It covers 16鑴?6 tiny text,
3000鑴?0 and 80鑴?000 strips, low contrast, rotation, blank input, dense synthetic
text, and 1920鑴?080 / 2560鑴?440 screenshots. The gate asserts bounded detection
counts, valid confidence/geometry, and high-confidence text anchors where exact
front-end parity is meaningful; rotated and density-only cases intentionally test
robustness rather than unstable line ordering.

```powershell
& 'D:\workprj\aicoder\.tmp\ocr-models\.venv\Scripts\python.exe' `
  .\bench\stress_regression.py `
  --cpp .\build\ppocr_demo.exe `
  --det D:\workprj\aicoder\.tmp\ocr-models\ppocrv6_tiny_det.onnx `
  --rec D:\workprj\aicoder\.tmp\ocr-models\ppocrv6_tiny_rec.onnx `
  --dict D:\workprj\aicoder\.tmp\ocr-models\dict_ppocrv6_tiny.txt `
  --images D:\workprj\aicoder\corelib\ocr\testdata\stress
```

Latest local run: **11/11 passed** (box counts: 123, 0, 1, 1, 20, 1, 3, 6, 743,
34, 38). This broadens the existing strict 7-image text-parity gate; it does not
weaken it.

### Recognition-regression corpus

`bench/accuracy_compare.py` compares complete C++ OCR results against an ONNX
Runtime CPU reference. Its default gate checks detected-line count and decoded
text; confidence and geometry are retained in the JSON report but do not gate
the test because the two standalone frontends have small resize/crop rounding
differences. Pass `--strict-geometry` to also gate those fields.

`bench/accuracy_expectations.json` supplies independently recorded expected
text for the deterministic corpus, so the same run also checks C++ results
against known text rather than only comparing two inference backends.

The latest 7-image corpus passed **7/7 text-parity cases**. It includes clean
multi-line English, a single word, a 3000-pixel-wide receipt line, a
low-contrast/noisy scene, a blank image, and a 16x16 tiny-text case. The
samples are existing deterministic test assets from
`D:\workprj\aicoder\corelib\ocr\testdata`.

An additional multilingual and extreme-shape sweep covers Chinese and mixed
language text, a 80x3000 vertical strip, rotated text, synthetic dense blobs,
and 1920x1080/2560x1440 screenshots. Chinese/mixed baseline samples retain
exact decoded-text parity. The pathological vertical/dense screenshot samples
remain diagnostic rather than release gates because detector/crop rounding can
alter weak low-confidence regions between the two independently implemented
frontends. `accuracy_compare.py` now forces UTF-8 report output so this corpus
can be run from a Windows GBK console without losing dictionary characters.

```powershell
$images = @(
  'D:\workprj\aicoder\corelib\ocr\testdata\en.png',
  'D:\workprj\aicoder\corelib\ocr\testdata\line_en.png',
  'D:\workprj\aicoder\corelib\ocr\testdata\stress\single_word.png',
  'D:\workprj\aicoder\corelib\ocr\testdata\stress\wide_strip_3000x80.png',
  'D:\workprj\aicoder\corelib\ocr\testdata\stress\noisy_lowcontrast.png',
  'D:\workprj\aicoder\corelib\ocr\testdata\stress\blank_800x600.png',
  'D:\workprj\aicoder\corelib\ocr\testdata\stress\tiny_16x16.png'
)
& 'D:\workprj\aicoder\.tmp\ocr-models\.venv\Scripts\python.exe' `
  .\bench\accuracy_compare.py `
  --cpp .\build\ppocr_demo.exe `
  --python 'D:\workprj\aicoder\.tmp\ocr-models\.venv\Scripts\python.exe' `
  --det 'D:\workprj\aicoder\.tmp\ocr-models\ppocrv6_tiny_det.onnx' `
  --rec 'D:\workprj\aicoder\.tmp\ocr-models\ppocrv6_tiny_rec.onnx' `
  --dict 'D:\workprj\aicoder\.tmp\ocr-models\dict_ppocrv6_tiny.txt' `
  --expectations .\bench\accuracy_expectations.json `
  --images $images
```

Captured report: `build/accuracy_ground_truth_7_ctctop1_sparse.json` (7/7
passed after batch/concurrent recognition and terminal-CTC reduction).

### Dynamic-size memory soak

`ppocr_mem_soak` keeps one C++ OCR instance alive while repeatedly alternating
tiny, wide-strip, noisy, and 1920x1080 UI images. It reports process-private
bytes after every complete mixed-size cycle. Intermediate tensors are released
after their final graph consumer, model weights remain immutable, and no
per-shape activation cache is retained. Detector results (including the large
probability map) are additionally scoped through DB post-processing and released
before concurrent recognition batches begin, so the allocator can reuse their
storage rather than combining detector and recognizer activation peaks.

The same process-level workload can be run against ONNX Runtime with
`bench/ort_mem_soak.py`. On this Windows host, using 12 mixed-size cycles:

| Engine | Baseline private bytes | Final private bytes | Final change |
|---|---:|---:|---:|
| Pure C++ PP-OCRv6 | 23.825 MiB | 24.633 MiB | +0.809 MiB |
| ONNX Runtime CPU | 145.371 MiB | 203.805 MiB | +58.434 MiB |

The current C++ run ranged from 22.735 MiB to 27.703 MiB after the baseline;
its final working set was 0.809 MiB above the immediate post-load baseline,
without a monotonic per-cycle increase. ONNX Runtime retained roughly 58 MiB
in the prior corresponding run. This is a process-private-memory measurement
for the specified machine and models, not a portable memory guarantee; rerun
it on the deployment target.

Build PPM copies for the native soak from the same PNG source files:

```powershell
$code = @'
from PIL import Image
from pathlib import Path
source = Path(r'D:\workprj\aicoder\corelib\ocr\testdata')
output = Path(r'.\build\mem_samples'); output.mkdir(exist_ok=True)
for name in ['stress/tiny_16x16.png', 'stress/wide_strip_3000x80.png',
             'stress/noisy_lowcontrast.png', 'stress/ui_dense_1920x1080.png']:
    Image.open(source / name).convert('RGB').save(output / (Path(name).stem + '.ppm'), format='PPM')
'@
$code | & 'D:\workprj\aicoder\.tmp\ocr-models\.venv\Scripts\python.exe' -
```

Then run the C++ side (replace the model paths if needed):

```powershell
.\build\ppocr_mem_soak.exe <det.onnx> <rec.onnx> <dict.txt> 12 `
  .\build\mem_samples\tiny_16x16.ppm `
  .\build\mem_samples\wide_strip_3000x80.ppm `
  .\build\mem_samples\noisy_lowcontrast.ppm `
  .\build\mem_samples\ui_dense_1920x1080.ppm
```

### Resolution ladder and post-large-image memory recovery

For a stricter retention check, generate a deterministic page ladder that
climbs from `16x16` through `3840x2160`, includes ultra-wide and ultra-tall
pages, and ends with another `64x64` page:

```powershell
& 'D:\workprj\aicoder\.tmp\ocr-models\.venv\Scripts\python.exe' `
  .\bench\generate_memory_ladder.py --output .\build\memory_ladder

.\build\ppocr_mem_soak.exe <det.onnx> <rec.onnx> <dict.txt> 2 `
  .\build\memory_ladder\ladder_16x16.ppm `
  .\build\memory_ladder\ladder_64x64.ppm `
  .\build\memory_ladder\ladder_160x120.ppm `
  .\build\memory_ladder\ladder_320x240.ppm `
  .\build\memory_ladder\ladder_640x480.ppm `
  .\build\memory_ladder\ladder_1280x720.ppm `
  .\build\memory_ladder\ladder_4096x256.ppm `
  .\build\memory_ladder\ladder_256x4096.ppm `
  .\build\memory_ladder\ladder_1920x1080.ppm `
  .\build\memory_ladder\ladder_2560x1440.ppm `
  .\build\memory_ladder\ladder_3000x1600.ppm `
  .\build\memory_ladder\ladder_3840x2160.ppm `
  .\build\memory_ladder\ladder_recovery_1920x1080.ppm `
  .\build\memory_ladder\ladder_recovery_4096x256.ppm `
  .\build\memory_ladder\ladder_recovery_256x4096.ppm `
  .\build\memory_ladder\ladder_return_64x64.ppm
```

For CI or a repeatable pass/fail report, run the bounded-recovery checker. It
records every resolution and requires the final `64x64` sample to remain
within 20% of both the warmed baseline and the final ultra-tall recovery
sample, as well as within 20% of the earlier `3840x2160` sample. The report
includes `declined_after_largest`, so allocator capacity retention
cannot be confused with an actual post-large-image recovery observation:

```powershell
& 'D:\workprj\aicoder\.tmp\ocr-models\.venv\Scripts\python.exe' `
  .\bench\memory_ladder_regression.py `
  --cpp .\build\ppocr_mem_soak.exe --det <det.onnx> --rec <rec.onnx> `
  --dict <dict.txt> --images .\build\memory_ladder --cycles 2 --backend cpu `
  --require-post-large-decline
```

`ppocr_mem_soak` loads, infers, and destroys one RGB image at a time and emits
one private-byte sample after every resolution.  The final small-page sample
is therefore the direct recovery observation after the staged 4K and
extreme-aspect-ratio tail; compare it with the `ladder_3840x2160` and final
`ladder_recovery_256x4096` samples and the next cycle rather than treating
the process allocator's high-water capacity as a leak.  Run the same command
with `PPOCR_BACKEND=hybrid` to include the persistent Vulkan buffers in the
process-level measurement.

The current generator intentionally uses an ascending, aspect-ratio-diverse
16-sample sequence: `16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 ->
1280x720 -> 4096x256 -> 256x4096 -> 1920x1080 -> 2560x1440 -> 3000x1600 ->
3840x2160 -> 1920x1080 -> 4096x256 -> 256x4096 -> 64x64`. The final staged
recovery tail checks that memory remains bounded after both 4K area and
extreme-aspect-ratio images. In addition to private bytes,
the native JSON now includes Windows working-set bytes for each measured
sample.  Private bytes remain the bounded-recovery gate; working set is
reported as complementary residency evidence because the Windows heap and
Vulkan driver may retain reusable committed capacity after the page and its
activations have been destroyed.

The generator also includes native **5K** (`5120x2880`) and **8K**
(`7680x4320`) source pages.  The 8K sample is followed immediately by a 4K
recovery sample, so use `--require-post-large-decline` to make both Windows
private bytes and working set decline at that exact transition a strict gate.
This catches source-image retention even though detector inference itself is
normally capped by `det_limit_side_len`.

### 2026-08-14: current small-to-large image-memory check

The checked-in generator was rerun against the current medium PP-OCRv6 CPU
build.  It creates the deterministic 16-image sequence above, processes each
image with one long-lived OCR instance, and destroys the decoded RGB image
before sampling process memory.  The result therefore measures retained
runtime/allocator capacity rather than intentionally retained source images.

In the current one-cycle run, private memory was **147,017,728 B** at
`3840x2160`, then immediately declined to **146,296,832 B** at the following
`1920x1080` sample (**-720,896 B**, **-0.49%**).  Working set also declined
from **150,679,552 B** to **150,085,632 B** (**-593,920 B**).  After the
complete recovery tail, the final `64x64` sample was **147,124,224 B** private
and **151,035,904 B** working-set memory: below the pre-return peak
(**148,320,256 B** private / **152,371,200 B** working set), and only **2.21%**
above the warmed private baseline (**143,937,536 B**).  The bounded-recovery
gate passed.  Full per-resolution evidence is
`build/memory_ladder_medium_cpu_current_20260814.json`.

Windows allocation is intentionally treated as a bounded-recovery result, not
as a requirement that every allocator page be decommitted immediately: the
explicit first-post-4K samples prove the observed downward transition, while
the final small-image sample guards the durable footprint after the whole
large-image sequence.

### 2026-08-13: current ascending-resolution memory measurement

With the current default recognizer batch size of 1, CPU backend, 16 kernel
workers, and approximate GELU, medium PP-OCRv6 passed a fresh one-cycle
ascending-resolution check. The run covers every generated image from
`16x16` through `3840x2160` (including `4096x256` and `256x4096`), then the
staged recovery tail and a final `64x64`. Private bytes were **147,234,816 B**
after `3840x2160` and **147,144,704 B** after the final `64x64`, a decline of
**90,112 B (0.06%)**. Working set likewise declined from **151,109,632 B** to
**150,913,024 B** (**196,608 B**). The final private-byte value was **0.008%**
above the fully warmed **147,132,416 B** baseline and 2.38% below the
pre-return peak, so every 20% bounded-recovery gate passed. The complete
per-resolution record is
`build/memory_ladder_medium_cpu_ascending_recheck_20260813.json`; values are
host-specific allocator observations, rather than a promise of immediate heap
decommit on every operating system.

### 2026-08-13: per-resolution memory-record validation

The ladder checker now preserves the private-byte and working-set sample for
**every** image resolution in its JSON report, together with the cycle peak
and a direct post-`2560x1440` recovery flag.  This makes the check suitable for
both leak detection and deployment profiling: a final small-page allocation is
not mistaken for the large-page allocation just because a heap or driver keeps
reusable capacity committed.

On the current AVX-512 Windows host, medium PP-OCRv6 with 16 kernel workers
and opt-in approximate GELU passed two fresh CPU ladder cycles.  The warmed
private baseline was **146,632,704 bytes**.  After `2560x1440`, the final
`64x64` sample was **148,533,248 bytes** in cycle 1 (+1.30% baseline, +2.00%
from the largest-page sample) and **143,220,736 bytes** in cycle 2 (-2.33%
baseline, -1.23% from the largest-page sample).  Thus direct private-byte
recovery occurred in the second cycle but not the first: Windows heap reuse
can retain or move committed capacity between samples.  Both final samples
remained within the 20% bounded-recovery limit, which is the pass/fail gate;
the JSON deliberately retains the explicit per-cycle recovery flag instead of
claiming unconditional decommit after a large image.

The same two-cycle Hybrid Vulkan run also passed.  Its warmed private baseline
was **394,969,088 bytes** and each final `64x64` sample was **396,017,664
bytes** (+0.265%).  The final private bytes equalled the immediately preceding
`2560x1440` sample in both cycles, while the working set was essentially flat
(+12,288 bytes in cycle 1 and +8,192 bytes in cycle 2).  This is persistent
Vulkan/Windows allocator capacity rather than evidence that an image or its
activations remain live.  These are machine-specific process measurements;
the exact per-resolution values are retained in
`build/memory_ladder_medium_{cpu,hybrid}_20260813.json` when the commands are
run locally.

On 2026-08-12, the current medium model passed this expanded two-cycle gate.
CPU warmed at **148,127,744 B** and returned to **147,148,800 B** and
**147,152,896 B** (both **-0.66%** of baseline); the final small-page samples
were 2.33% and 1.70% above their immediately preceding largest-page samples.
Hybrid Vulkan warmed at **393,490,432 B** and returned at **395,317,248 B**
(+0.46%) and **395,341,824 B** (+0.47%).  All private-byte deltas passed the
20% gate.  The resident working-set observations are also captured in the
checker output rather than being inferred from private bytes; on this shared
Windows host they remained within the allocator/driver's warmed range, not a
claim that either heap must promptly decommit pages.

On 2026-08-12, the tiny model with 16 CPU workers was run through this exact
seven-image ladder.  CPU-only warmed to **9,400,320 bytes**; after the largest
`2560x1440` page its next small-page sample was **9,465,856 bytes**
(**+65,536 bytes**, 0.7% of baseline).  Hybrid warmed to **116,305,920 bytes**
and the corresponding post-large small-page sample was **115,802,112 bytes**
(**-503,808 bytes**).  These per-image values show recovery after the largest
input for both modes.  They are Windows private-byte observations on this
host, not a cross-platform leak proof or a fixed memory guarantee.

The same seven-page gate was rerun after the depthwise-pointwise-GELU graph
fusion with the **medium** PP-OCRv6 model (two measured cycles, default bounded
CPU scheduler).  Both modes passed the 20% bounded-recovery limits:

| Backend | Warmed baseline | Final `64x64`, cycle 1 | Final `64x64`, cycle 2 | Result after `2560x1440` |
|---|---:|---:|---:|---|
| CPU | 136.351 MiB | 140.019 MiB (+2.69%) | 140.008 MiB (+2.68%) | Allocator private bytes did not immediately decline, but remained stable and 2.24閳?.29% above the largest-page sample. |
| Hybrid Vulkan | 360.574 MiB | 361.582 MiB (+0.28%) | 361.582 MiB (+0.28%) | Equal to the immediately preceding largest-page sample in both cycles. |

The CPU observation is expected on Windows: completed image and activation
objects have been destroyed, while the process allocator may retain reusable
blocks.  Consequently the test reports both `declined_after_largest` and the
bounded deltas instead of treating an unchanged private-byte high-water mark
as proof of a live-image or tensor leak.  The Hybrid samples include its
persistent Vulkan allocations.

The same CPU-only one-cycle ladder was also run for the other two PP-OCRv6
sizes: small warmed to **37,662,720 bytes** and returned at
**38,973,440 bytes** after its largest page (**+1,310,720 bytes**); medium
warmed to **147,435,520 bytes** and returned at **148,439,040 bytes**
(**+1,003,520 bytes**).  In both cases the return sample remained within 3.5%
and 0.7% of their post-warm-up baselines respectively, with no retained RGB
source images between calls.

The reusable checker was then run for two full ladders after the per-image
sampler change.  All three CPU models passed the 20% bounded-recovery gate:
tiny returned within **+1.14%**, small within **+10.09%**, and medium within
**+2.46%** of their warmed baselines; each final `64x64` sample was also at or
below the pre-large `1920x1080` sample except medium's first cycle (**+0.81%**).
Tiny hybrid also passed, returning within **+0.08%** of baseline, including
the persistent Vulkan allocation.  These figures are deliberately a bounded
allocator-reuse test, not an assertion that Windows must immediately release
committed heap pages to the OS.

The current checker also makes the immediate recovery result explicit.  On a
fresh two-cycle tiny run with the default 12 workers, CPU warmed to
**10,047,488 bytes** and returned at **9,379,840** then **9,441,280 bytes**;
both cycles reported `declined_after_largest=true` (2.97% and 9.64% below the
preceding `2560x1440` samples).  Hybrid warmed to **135,745,536 bytes** and
returned at **135,098,368** then **135,102,464 bytes**, both below its warmed
baseline but **not** immediately below the preceding largest-image samples
(`declined_after_largest=false`, +1.24% and +0.63%).  This distinction is
intentional: the test reports the actual post-large behavior and separately
enforces bounded recovery, rather than incorrectly claiming immediate heap
release for persistent Vulkan/Windows allocator capacity.

### 2026-08-12: current ascending-resolution memory check

The deterministic seven-image ladder was regenerated and rerun on the current
binary: `64x64 -> 320x240 -> 640x480 -> 1280x720 -> 1920x1080 -> 2560x1440
-> 64x64`.  Each sample performs `load -> Recognize -> destroy ->
PrivateBytes`, so the reported process-private bytes include runtime working
memory but do not retain the source RGB page between samples.  The bounded
20% return gate passed in every run below.

| Model / backend | Warmed baseline | Cycle 1 final 64x64 | Cycle 2 final 64x64 | Post-largest result |
|---|---:|---:|---:|---|
| tiny / CPU | 9,367,552 B | 9,412,608 B (+0.48%) | 9,424,896 B (+0.61%) | Fell below the preceding 2560x1440 sample in both cycles (11.17%, 1.75%). |
| medium / CPU | 148,254,720 B | 146,284,544 B (-1.33%) | 147,300,352 B (-0.64%) | Bounded return; final sample was 1.08% / 2.65% above the immediately preceding large sample. |
| tiny / hybrid Vulkan | 115,851,264 B | 99,143,680 B (-14.42%) | 98,140,160 B (-15.29%) | Bounded return; final sample was 0.004% / 0.017% above the immediately preceding large sample. |

`declined_after_largest` is therefore true for the CPU tiny run and false for
the medium CPU and hybrid runs.  That false value is an observation, not a
leak verdict: Windows heap and persistent Vulkan allocations may retain or
rearrange reusable capacity.  The two complementary checks閳ユ敄he final-small
sample versus its post-warm-up baseline and the stated largest-page
comparison閳ユ攷ake the memory behavior auditable without claiming that a process
must immediately return committed pages to the OS.

After the subsequent depthwise-pointwise-GELU fusion, the medium ladder was
rerun with two cycles.  CPU warmed at **142,974,976 B**; its final `64x64`
samples were **146,821,120 B** (+2.69%) and **146,808,832 B** (+2.68%).
They were 2.29% and 2.24% above the respective `2560x1440` samples, so
`declined_after_largest=false`, yet both are stable and well within the 20%
bounded-return gate.  Hybrid warmed at **378,089,472 B** and returned at
**379,146,240 B** in both cycles (+0.28%); each final small image equalled its
preceding largest-image sample (`declined_after_largest=true`).  Thus the
test continues to distinguish released OCR image/tensor lifetimes from normal
Windows heap or persistent Vulkan capacity retention.

### 2026-08-12: admitted depthwise-to-pointwise Vulkan segment

The graph loader now recognizes an exact `depthwise Conv(bias) -> 1x1
pointwise Conv(bias)` pair and emits `FusedDepthwisePointwiseConv`.  Its CPU
path remains the same two SIMD kernels, while hybrid can submit the existing
Vulkan chain in one command buffer: the depthwise result stays in a device
storage buffer and only the chain boundaries transfer.  Admission is cached
per full NCHW geometry and accepts GPU only after a repeated H2D + dispatch +
fence + D2H comparison and elementwise CPU-result validation show that the
complete segment is no slower.  Consequently this reduces CPU occupancy when
the Radeon/driver wins without forcing a transfer-bound GPU route.

The feature covers the detector MobileNet backbone pairs in all three model
sizes.  AVX-512 kernel smoke and the four diverse decoded-text comparisons
for tiny, small and medium all passed (**12/12**).  The current Radeon 780M
primitive probe measures a representative depthwise-to-pointwise batch at
**0.76714 ms GPU vs 0.20474 ms CPU**, so this particular UMA shape is
correctly rejected; it is evidence that the new graph route retains the
no-slower policy rather than a claim of blanket GPU acceleration.  A current
20-run CPU-only `en.ppm` snapshot (16 kernel workers, approximate GELU)
measured tiny **27.954 ms**, small **60.455 ms**, and medium **195.588 ms**.
`gpu_only` still fails explicitly because the complete PP-OCRv6 graph,
post-processing and CTC decode are not yet device resident; it never silently
falls back to CPU.

### 2026-08-12: depthwise-to-pointwise CPU graph fusion

The same strict MobileNet `depthwise Conv(bias) -> 1x1 pointwise Conv(bias)`
pattern now executes as one graph node on CPU too.  It removes the executor's
hash-map entry, node dispatch and intermediate tensor lifetime from the graph;
the internal temporary remains only for the two exact SIMD kernels.  This is
an intentional graph/lifetime fusion, not a mathematical approximation.  Set
`PPOCR_DISABLE_DEPTHWISE_POINTWISE_FUSION=1` for an A/B fallback.

On the current 16-worker AVX-512 host, three warm-ups and fifteen `en.ppm`
runs showed the fused path at **26.784 / 56.596 / 174.962 ms** for tiny,
small and medium, respectively, compared with **27.121 / 58.209 / 228.572
ms** with the graph fusion disabled.  The medium result is host-scheduling
sensitive, so the reproducible conclusion is the consistent no-regression
and gains for tiny/small, while deployment owners should rerun the medium A/B
on their target CPU. A separate 20-run medium A/B measured **213.711 ms**
fused versus **222.719 ms** disabled.  The exact decoded-text gate passed
**12/12** across tiny/small/medium and four diverse inputs.  A two-cycle
medium resolution ladder also passed the bounded memory-recovery gate:
147,255,296-byte warmed baseline; final small-page samples were -0.68% and
-0.08% from baseline.  As elsewhere, the final samples did not immediately
fall below the preceding maximum-size sample, which is normal reusable
Windows allocator capacity rather than a leak assertion.

### 2026-08-12: depthwise-pointwise-GELU liveness fusion

The loader now extends that exact single-use pattern through an immediately
following fused GELU as `FusedDepthwisePointwiseConvGelu`.  The pointwise
output is activated in place, rather than re-entering the generic graph loop
to rename and transform it.  It preserves FP32 operation order (the same
existing GELU kernel runs after the two convolutions) and keeps the Vulkan
segment's no-slower admission boundary intact; a selected GPU segment still
returns before the exact CPU GELU pass.  The targeted A/B escape hatch is
`PPOCR_DISABLE_DEPTHWISE_POINTWISE_GELU_FUSION=1`.

The AVX-512 kernel smoke and the 12/12 decoded-text ONNX Runtime gate passed.
On this shared host, a 15-run `en.ppm` A/B did not establish a uniform
latency benefit: tiny was 29.137 vs 28.908 ms, small 62.292 vs 62.007 ms,
and medium 205.199 vs 221.369 ms (fusion enabled vs disabled).  It is retained
because it removes a graph-lifetime boundary and shows a medium improvement,
but the table intentionally does not promote it to a universal CPU speedup.

### 2026-08-12: expanded batched ordinary-Conv SIMD coverage

`Conv2dBatch()` now carries the batch index through the existing runtime-gated
SIMD kernels for valid `2x2`, padded `5x5`/`7x7`, and asymmetric
`1x3`/`3x1`/`1x5`/`5x1` stride-one convolutions, in addition to the prior
`3x3` stride-one/two paths.  This removes one worker-pool dispatch per crop
for the medium detector's context layers while preserving each output's
increasing-channel/kernel accumulation order.  AVX-512 is selected only after
the existing CPUID/XCR0 guard; AVX2 and portable/NEON paths retain their safe
fallback behavior.

The low-level smoke now compares N=3 batched output against three independent
calls for all of those shapes and ReLU tails.  It passed with normal AVX-512
dispatch and with `PPOCR_DISABLE_AVX512=1` (AVX2 fallback).  A post-change
four-identical-page medium CPU batch test (`det_batch_size=4`,
`rec_batch_size=4`, three measured runs) was result-identical and measured
**793.299 ms** serial versus **710.437 ms** batched (**1.117x**).  The same
tiny hybrid configuration was result-identical and measured **126.750 ms**
serial versus **85.669 ms** batched (**1.480x**).  These are local scheduler
measurements, not a universal Vulkan claim: the concurrent Vulkan primitive
smoke continued to select GPU only for its no-slower affine+Swish probe and
retained CPU for the transfer-bound Conv and GEMM probes.

The full small-to-large-to-small CPU ladder was rerun for all model sizes with
the expanded kernels.  All passed the three 20% bounded-recovery limits.
Observed final-small change from the post-warm baseline was tiny **+1.72%**
and **+8.51%**, small **-1.57%** and **+8.90%**, and medium **+0.70%** and
**+0.02%** over two cycles.  `declined_after_largest` is retained as a fact
rather than a pass condition, because Windows heap trimming is nondeterministic
even when the runtime has released the input and activation vectors.

### 2026-08-12: default AVX-512 wide-context Conv tile

The AVX-512 eight-output tile for the PP-OCRv6 medium detector's `5x5` and
`7x7` context layers is now enabled by default for its narrow, runtime-checked
shape (`C_in >= 32`, `C_out >= 8`, and both spatial dimensions at least 32).
It reuses each input vector across eight output reductions; smaller shapes,
AVX2, NEON, and scalar targets retain their existing paths. Set
`PPOCR_DISABLE_AVX512_CONV_WIDE8=1` for a deployment-local A/B test.

On the local AVX-512 host with 12 workers, three warm-ups and twelve `en.ppm`
runs, medium CPU measured **424.234 ms** with the tile and **659.937 ms** with
`PPOCR_DISABLE_AVX512_CONV_WIDE8=1` (same model/input; shared-host variation
is reflected by the recorded medians **404.622 / 668.809 ms**).  Fresh
ONNX-Runtime decoded-text comparison remained **12/12** across tiny, small,
and medium on `16x16`, English, low-contrast, and `3000x80` inputs. The medium
two-cycle `64x64 閳?2560x1440 閳?64x64` ladder also passed all bounded-memory
checks, ending at **+0.19%** and **+2.72%** from its warmed baseline. Vulkan
primitive smoke remained numerically passing; hybrid selected only its
measured no-slower affine+Swish and depthwise+Swish samples in that run.

### 2026-08-12: medium worker and transpose-tile recheck

A fresh worker sweep after the wide-context default confirms the library's
automatic **16-worker** ceiling remains appropriate for the broad medium
graph, while tiny/small retain their shorter-kernel behavior: on the same
`en.ppm` setup, medium measured **191.664 / 205.187 / 185.906 ms** with
8/12/16 workers; tiny measured **28.434 / 28.797 ms** and small
**57.390 / 59.147 ms** at 12/16 workers.  The 16-worker medium CPU retest
(3 warm-ups, 20 runs) averaged **185.325 ms**; paired ONNX Runtime CPU on the
same image/run count averaged **260.194 ms**, a host-specific **28.8%** lower
native latency.

The AVX-512 four-output `ConvTranspose2x2` FPN experiment was rechecked too.
It measured **186.232 ms** versus **181.971 ms** for the established
single-output implementation (3 warm-ups, 10 runs), so it remains opt-in via
`PPOCR_ENABLE_AVX512_TRANSPOSE2X2_TILE4=1`; it is not promoted merely because
it reduces some input loads. This preserves the faster default and avoids a
regression on the current target.

### 2026-08-12: device-resident depthwise/pointwise Vulkan segment

The Vulkan backend now has a numerically checked two-dispatch MobileNet
`depthwise Conv -> 1x1 pointwise Conv` primitive.  It uploads the chain input
once, leaves the depthwise feature map in a mapped Vulkan storage buffer,
inserts an explicit compute shader write-to-read memory barrier, and reads
back only the pointwise result.  Its hybrid admission measures that complete
boundary against the corresponding CPU `DepthwiseConvBatch` plus
`PointwiseConvBatch` pair and rejects Vulkan when it is slower.

On the local Radeon 780M / AVX-512 host, the odd-shape batched numerical smoke
passed, but the representative `N=4, C=32, M=40, 31x29, 3x3` full-boundary
probe measured **0.836 ms Vulkan vs 0.271 ms CPU**.  Hybrid therefore keeps
the CPU path for this segment.  The primitive is deliberately not folded into
the production ONNX graph yet: its current model-level floating-point drift
needs a decoded-text tolerance gate before any performance claim or default
dispatch change.  This preserves exact production behavior while retaining a
real, barrier-validated GPU building block for subsequent fully-resident
segments.

The batch smoke executable now also prints its individual timed samples, so a
throughput claim can be audited for scheduler outliers rather than relying on
one aggregate number.  With four equal `en.ppm` pages, batch size four, 16 CPU
kernel workers, two warm-ups and eight timed runs, CPU serial閳妼atch results
were **120.826閳?5.704 ms (1.410x)** for tiny, **281.621閳?27.853 ms (1.236x)**
for small, and **859.114閳?44.174 ms (1.018x)** for medium. Hybrid under the
same batch settings measured **166.786閳?08.215 ms (1.541x)** tiny,
**331.511閳?51.555 ms (1.318x)** small, and **824.029閳?49.212 ms (1.100x)**
medium. Serial/batch OCR outputs were byte-for-byte equivalent in each run.
The hybrid figures are page-batching capacity gains; they do not claim that
the partial Vulkan graph is faster than CPU for every single page.

A fresh 12-cycle run after this lifetime change used a 23.488 MiB baseline and
finished at 26.664 MiB (+3.176 MiB); its cycle deltas ranged from -0.543 MiB to
+4.055 MiB with no monotonic growth. Windows heap retention makes the final
private-byte delta workload- and allocator-dependent, so the important release
criterion is the non-growing mixed-shape sequence, not a single final number.

After the batched constant-weight MatMul change, a medium-model two-cycle
mixed-size check covering `16x16`, `3000x80`, `80x3000`, and the 119-box
`1920x1080` UI page used **293,961,728 bytes** after warm-up; the two cycle
measurements were **811,008 bytes below** and **471,040 bytes below** that
baseline. This verifies that flattening a batch is a scheduling change, not a
per-shape tensor cache or an activation-retention increase. As above, it is a
Windows allocator-capacity observation rather than a universal leak proof.

After adding the Vulkan channel-affine batch buffers, the same medium mixed
sequence was rerun for two cycles with the default hybrid policy. Its
post-warm-up baseline was **290,508,800 bytes**; cycles finished at
**+5,214,208** and **+2,506,752 bytes**. The high-water movement is bounded
Windows allocator retention after the large UI page, not a per-cycle growth
trend; GPU affine admission was rejected on this host, so the extra persistent
Vulkan coefficient storage was not exercised by the CPU execution path.

After the BatchNorm-Swish in-place activation update, a fresh CPU medium
mixed-size soak (`16x16`, `3000x80`, `80x3000`, and the dense `1920x1080` UI
page) used **286,793,728 bytes** post-warm-up. Its next two cycles were
**9,101,312** and **5,144,576 bytes below** baseline. This is a bounded
allocator observation on Windows, but it confirms the source-buffer reuse does
not retain changing-shape recognition activations.

The captured C++ and ONNX Runtime reports are
`build/memory_soak_cpp_12.json` and `build/memory_soak_ort_12.json`. A
post-optimization 6-cycle C++ check is also retained as
`build/memory_soak_cpp_parallel4_6.json`: it finished 1.034 MiB below its
24.629 MiB post-warmup baseline, demonstrating that bounded concurrent
recognition does not retain every dynamic input shape.

### 2026-08-12: cross-page recognition batching

`OCR::RecognizeBatch` now keeps dynamic detector resizing per page, then
coalesces equal-width crops from all submitted pages into bounded NCHW
recognizer batches. This is useful for both CPU SIMD and the Vulkan batch-Y
dimension; it does not pad unrelated detector pages, does not change result
order, and releases each detector probability map before recognition starts.

On this Radeon 780M / Windows host, medium PP-OCRv6, four copies of `en.ppm`,
`rec_batch_size=8`, one recognizer worker and one detector worker:

| Path | Serial pages | Cross-page batched | Speedup |
|---|---:|---:|---:|
| CPU | 773.012 ms | 744.098 ms | 1.039x |
| Hybrid | 854.746 ms | 1249.711 ms | 0.684x |

The batch smoke test confirms exact public `Result` equivalence with serial
inference. Hybrid is intentionally not presented as a win here: the current
UMA Vulkan implementation admits each segment only when its complete transfer
+ dispatch + readback path is no slower than CPU, while the coalesced workload
still has significant CPU-only graph work. Four-image mixed-size CPU coverage
(`en`, low-contrast, wide strip, dense 1920x1080 UI; 128 results) also passed
the serial-result check at 1.004x. A tiny-model four-page CPU check measured
143.472 ms serial and 139.913 ms batched (1.025x). Re-run these workloads on
the deployment hardware; they are measurements, not portability claims.

### 2026-08-12: depthwise Vulkan batch kernel and hybrid batch gate

The Vulkan depthwise-convolution path now maps one workgroup to one NCHW
channel and up to 1,024 output pixels. Its `[KH,KW]` filter is cooperatively
staged in workgroup memory (up to `16x16`), while Vulkan's Y dimension remains
the independent crop-batch dimension. PP-OCRv6's MobileNet-style depthwise
filters therefore avoid reloading the same channel filter for every output
pixel. Larger exported filters safely use the existing global-memory fallback.

The Radeon 780M numerical smoke test passed for a padded `N=2, C=5, 7x9,
3x3` depthwise batch. Its latest complete synchronous measurement was
**0.44340 ms GPU / 0.35062 ms CPU**, so the strict H2D + dispatch + D2H
admission policy correctly retained the CPU SIMD path for that shape. This is
an optimized, batch-capable GPU primitive, not a claim that the incomplete
GPU-resident OCR graph is faster on this UMA GPU.

The same build also ran the public batch-equivalence harness on tiny PP-OCRv6
with `rec_batch_size=8`, one detector worker and one recognizer worker across
four varied pages (`en`, low-contrast, `3000x80`, dense `1920x1080`). All
**129** decoded results matched serial `Recognize()` exactly. The one-shot
local measurement was **1081.928 ms serial / 1167.667 ms batched** for CPU and
**1105.010 ms serial / 1075.921 ms batched** for hybrid. These scheduler
samples are intentionally retained as measurements rather than a universal
throughput promise; the dense mixed-width workload has limited equal-width
crop coalescing. A separate CPU-versus-hybrid dense-page result comparison was
also byte-for-byte identical.

### 2026-08-12: cross-crop CPU pointwise scheduling

The CPU 1x1-convolution path now accepts a real NCHW batch in one scheduling
call. On x86 it flattens `(crop N, output-channel tile)` into the persistent
AVX-512/AVX2 worker queue, retaining the existing per-channel FP32 reduction
order and ISA-specific four/eight-output vector kernels. ARM/NEON and scalar
builds retain their portable per-crop path. This removes repeated worker-pool
barriers for batchable recognizer projections without changing the model graph
or requiring ONNX Runtime.

The strict CPU-versus-ONNX Runtime decoded-text gate passed **4/4** varied
inputs (`en`, `16x16`, low-contrast, `3000x80`) for **tiny, small, and
medium** after this change. The five-page public batch gate (also adding dense
`1920x1080`) passed serial-result equivalence for all three models: tiny
**130**, small **126**, medium **129** results. A local one-worker CPU batch
sample measured **0.948x / 1.162x / 1.014x** page-batch throughput for
tiny/small/medium respectively; the mixed dimensions intentionally make this
an evidence point rather than a universal latency claim. Hybrid revalidation
also preserved exact serial results at **1.003x / 1.036x / 0.983x**.

On `en.ppm`, 2 warm-ups and 6 timed CPU runs with 16 workers, the current
native means were **44.193 ms / 84.184 ms / 256.530 ms** for tiny/small/medium.
The matched ONNX Runtime CPU samples were **127.640 ms / 244.623 ms /
513.763 ms**, corresponding to **2.89x / 2.91x / 2.00x** native latency
advantages on this host. Windows scheduling remains variable; these are
repeatable local observations, not a portable capacity guarantee.

The five-size, two-cycle memory soak (`16x16`, `en`, low-contrast, `3000x80`,
`1920x1080`) remained bounded. Its warmed baselines and final deltas were:
tiny **113,876,992 / +3,874,816 bytes**, small **150,462,464 / -2,027,520
bytes**, and medium **385,916,928 / -3,629,056 bytes**. The small movements are
Windows allocator high-water behavior rather than a leak assertion.

### 2026-08-12: batched residual 1x1 projection scheduling

Fused `Conv(1x1) -> Add`, `Conv(1x1) -> Add -> ReLU`, and `Conv(1x1) -> Add
-> Swish` now have NCHW batch kernels. On x86, one work queue covers all
`(crop, output-channel SIMD tile)` tasks: AVX-512 uses the established
four/eight-output tiles and AVX2 uses four-output tiles. ARM/NEON and scalar
builds safely retain the per-crop implementation. The Swish variant completes
the batched fused convolution/add first, then applies the existing vector
Swish once across the whole contiguous NCHW allocation; FP32 reduction and
activation order are unchanged.

`ppocr_kernel_smoke` verifies the new Add, Add+ReLU, and Add+Swish batch
kernels against their single-crop counterparts for both SIMD-tail and large
work cases. It also passed with `PPOCR_DISABLE_AVX512=1`, exercising the AVX2
fallback. `PPOCR_DISABLE_RESIDUAL_POINTWISE_BATCH=1` is available solely as a
per-process A/B escape hatch; it restores the prior per-crop calls.

The four-image decoded-text comparison with ONNX Runtime remained **4/4** for
each tiny, small, and medium model. The five-size public batch-equivalence
gate also matched all serial `Result`s exactly: tiny **130**, small **126**,
medium **129**. One local CPU sample (one detector/recognizer worker,
`rec_batch_size=8`) measured serial/batch times of **909.483/907.159 ms**
(tiny, **1.003x**), **2780.569/2882.623 ms** (small, **0.965x**), and
**6781.126/6750.499 ms** (medium, **1.005x**). Mixed crop widths limit
coalescing, so these are recorded measurements rather than a portability
claim. Hybrid correctness was retained on the same corpus: tiny **1.134 s /
1.132 s** (0.994x), small **3.978 s / 3.515 s** (1.132x), and medium **7.024 s
/ 7.464 s** (0.941x). The hybrid backend still admits each Vulkan segment only
after a complete transfer + dispatch + readback no-slower check; the project
does not claim a fully GPU-resident graph or enable `gpu_only`.

### 2026-08-12: cross-crop CPU depthwise scheduling

The MobileNet depthwise CPU fallback now accepts the leading NCHW batch
directly. It flattens independent `(crop, channel)` jobs into one persistent
worker-pool pass, while each job continues to use the existing runtime-selected
AVX-512, AVX2, NEON, or scalar depthwise kernel. This removes repeated batch
loop scheduling around the dominant depthwise backbone stages without changing
the per-channel FP32 multiply/add order. The Vulkan depthwise route remains
separate and still receives the entire NCHW batch in one dispatch whenever its
complete transfer + dispatch + readback admission measurement is no slower
than CPU.

The extended kernel smoke tests padded/stride-1 `3x3` and padded/stride-2
`5x5` depthwise batches against the established per-image implementation; both
the normal AVX-512 run and `PPOCR_DISABLE_AVX512=1` AVX2 fallback passed. The
four-image decoded-text comparison with ONNX Runtime remained **4/4** for each
tiny, small, and medium model. The five-size batch-result gate likewise
remained exact (tiny **130**, small **126**, medium **129** results).

On the varied five-page corpus with `rec_batch_size=8` and one recognition
worker, this local CPU sample measured serial/batch throughput of **1.096x**
(tiny: 1000.988/913.176 ms), **0.992x** (small: 2855.215/2878.902 ms), and
**1.006x** (medium: 6922.651/6881.270 ms). Crop-width diversity constrains
batch density, so the figures are intentionally recorded as host-specific
measurements. Hybrid preserved serial-result identity at **1.011x**, **1.058x**
and **0.924x** for tiny/small/medium; GPU segments were retained only when the
strict no-slower admission test passed. A renewed five-size/two-cycle memory
soak stayed bounded: tiny baseline **99,737,600**, final **+716,800** bytes;
small baseline **148,520,960**, final **+1,306,624** bytes; medium baseline
**384,311,296**, final **-3,907,584** bytes.

### 2026-08-12: batched ordinary 3x3 convolution scheduler

The group-1 non-pointwise convolution path now supports NCHW batches. For the
common `3x3` stride-1 and stride-2 OCR shapes it flattens crop and established
AVX output-channel tiles into one persistent-pool submission: AVX-512 retains
its four/eight-output tile selection; AVX2 retains four-output stride-1 tiles
and its stride-2 kernel. ARM/NEON and non-3x3 geometries continue through the
existing per-image `Conv2d` path. This changes scheduling only, not the output
channel reduction order. `PPOCR_DISABLE_CONV_BATCH=1` restores the previous
per-crop dispatch for deployment A/B work.

The extended kernel smoke checks stride-1 tail, large AVX-512 tile, and
stride-2 ReLU batches against the prior single-image path; both AVX-512 and
forced AVX2 runs pass. ONNX Runtime decoded-text comparisons again passed
**4/4** for each tiny/small/medium model. On the five-size corpus with one
recognizer worker and `rec_batch_size=8`, the latest CPU serial/batch samples
were tiny **839.965/822.967 ms** (1.021x), small **2602.329/2656.020 ms**
(0.980x), and medium **6507.553/6500.383 ms** (1.001x), all with exact public
batch results. A consecutive A/B sample with `PPOCR_DISABLE_CONV_BATCH=1`
measured **1.023x / 0.966x / 1.005x** on the same mixed-width suite; host noise
and limited same-width coalescing outweigh this small scheduling change there,
so no universal speedup is claimed. Hybrid result equivalence held at
**1.009x / 0.778x / 0.979x**; Vulkan continues to be selected only by its
complete no-slower segment measurement.

### 2026-08-12: batched pointwise HardSwish projection

The remaining fused `1x1 Conv -> HardSwish` CPU path now shares the existing
cross-crop pointwise SIMD scheduler. It performs all NCHW projections through
`PointwiseConvBatch`, then runs one contiguous exact HardSwish pass over the
final allocation, instead of issuing the projection/activation once per crop.
This preserves the Conv FP32 reduction order and the canonical HardSwish
formula; AVX-512, AVX2, NEON, and scalar dispatch remain runtime portable.

Kernel smoke now compares both tail and large batched HardSwish projections to
the established per-crop routine. Normal AVX-512 and forced AVX2 execution
passed. The four-input ONNX Runtime decoded-text gate again passed **4/4** for
tiny, small, and medium, and the varied five-page batch gate remained exactly
identical to serial results (130 / 126 / 129 results). Latest CPU
serial/batch samples on that suite were tiny **901.083/842.421 ms** (1.070x),
small **2515.113/2599.535 ms** (0.968x), and medium
**6177.222/6239.080 ms** (0.990x). Hybrid samples were **0.996x / 1.250x /
0.972x**. These mixed-width measurements are evidence, not portability
claims; each Vulkan segment continues to require its own complete no-slower
transfer/dispatch/readback admission.

### 2026-08-12: batched FPN 2x2 transposed convolution

The detector's `2x2`, stride-two `ConvTranspose` FPN fast path now accepts
NCHW batches. It flattens `(crop, output-channel tile)` into one scheduling
pass: AVX-512 keeps its optional four-output reuse tile (or one-output default)
and AVX2 uses its established channel kernel; ARM/scalar builds retain the
same portable per-image routine. This preserves each output channel's ordered
input-channel accumulation and eliminates repeated batch-loop scheduling.

`ppocr_kernel_smoke` now validates small tail and large square batch cases
against the prior per-image FPN kernel, on both normal AVX-512 and forced AVX2
paths. The tiny/small/medium ONNX Runtime decoded-text checks again passed
**4/4** each. The five-size public batch gate stayed serial-identical at
130/126/129 results. Latest CPU serial/batch observations were tiny
**808.237/821.381 ms** (0.984x), small **2467.217/2557.340 ms** (0.965x), and
medium **6063.649/6071.106 ms** (0.999x). This page mix does not batch detector
shapes and has diverse recognition widths, so it should not be read as a
universal throughput claim. Hybrid exact-result samples were **1.019x / 0.859x
/ 0.974x**. The renewed medium five-size/two-cycle soak remained bounded
(baseline **384,970,752** bytes; final delta **+3,231,744** bytes), and Vulkan
smoke retained strict complete-segment admission.

### 2026-08-12: batched ordinary-convolution Vulkan path

Vulkan hybrid execution now also covers ungrouped, non-dilated ordinary NCHW
convolution (`3x3` and `2x2` detector forms), in addition to the existing
pointwise and depthwise paths.  The new shader maps a real crop batch to its
Y dimension and writes four adjacent output values per invocation where
possible.  Learned `[M,C,KH,KW]` weights and `[M]` bias retain their compact
layouts and are cached for immutable ONNX initializers; an immediately fused
ReLU can complete before the only D2H copy.  Asymmetric-stride, grouped, and
dilated convolutions deliberately retain the established CPU SIMD path.

This remains a *hybrid* primitive, not a GPU-only claim.  Every shape is
first validated against the CPU batched convolution and admitted only when its
complete H2D + dispatch + fence wait + D2H time is no slower.  The new Vulkan
smoke test covers padded stride-one and stride-two `N=3,C=4,M=7,3x3` batches,
including fused ReLU and scalar output tails.  On the local AMD Radeon 780M,
the larger admission sample (`N=4,C=24,M=40,31x29,3x3,ReLU`) measured
**3.53696 ms GPU / 0.83228 ms CPU** after the shared-filter tile optimization,
so the production policy correctly kept
that shape on CPU rather than adding GPU overhead.

After the change, the five-size public batch-equivalence harness preserved
serial output identity for all official model sizes under `PPOCR_BACKEND=hybrid`
with recognizer batch size 8: tiny **130** results (**1188.492 / 1163.981 ms**, 
**1.021x** serial/batch), small **126** (**3425.233 / 3507.859 ms**, **0.976x**),
and medium **129** (**7949.857 / 8198.539 ms**, **0.970x**).  These are
host-specific mixed-size scheduler samples, not a universal GPU-performance
promise.  `gpu_only` remains unavailable until the entire detector and
recognizer graph is device-resident.

### 2026-08-12: final-use BatchNormalization storage reuse

Standard inference `BatchNormalization` nodes now use the same NCHW
channel-affine kernel as fused normalization paths.  When graph liveness
proves that the input has reached its final use, the executor applies the
precomputed `scale / sqrt(variance + epsilon)` and `bias - mean * scale`
directly in that dying allocation, then renames it to the output.  This avoids
one complete activation allocation and copy for each eligible unfused node.
The official model bundle folds most normalisation nodes at load time, so this
extends compatible PP-OCRv6 graph coverage rather than being represented as a
separate current-model speedup.  The new
`BatchNormAffine` primitive is alias-safe and dynamically dispatches through
AVX-512, AVX2, NEON, or scalar `ScaleShift`; it is used in both `Run()` and
the recognizer's real `RunCtcTop1()` path.  `PPOCR_DISABLE_BATCHNORM_INPLACE=1`
is available for deployment A/B checks.

Kernel coverage now includes separate out-of-place and in-place batch-affine
numeric tests, and passed with both default AVX-512 dispatch and forced AVX2.
The post-change C++/ONNX Runtime decoded-text gate passed **4/4** varied
images (`16x16`, normal English, `3000x80` strip, noisy low-contrast) for
both tiny and medium.  A five-size medium two-cycle memory soak remained
bounded at a **457,703,424-byte** post-warm-up baseline; cycles ended at
**-9,195,520** and **+1,744,896 bytes**, consistent with allocator
high-water reuse rather than per-cycle growth.  The same five-size hybrid
tiny batch equivalence test returned all **130** decoded results identically
to serial inference (**1123.880 / 1118.024 ms**, **1.005x** serial/batch).
These are validation measurements, not a claim that every normalisation node
or GPU segment is faster on every host.

### 2026-08-12: batched Vulkan FPN transpose-convolution path

The detector FPN's `ConvTranspose(2x2, stride=2)` projection now has a
dedicated batched Vulkan primitive.  Its no-padding geometry has no overlap
between output tiles, so each output pixel maps directly to one input pixel
and one `[Cin,Cout,2,2]` filter tap; this avoids an expanded intermediate.
The kernel accepts NCHW batches, caches immutable model parameters in the
persistent Vulkan context, and uses one output readback.  The command
dispatcher was also corrected to submit workgroups (256 four-float
invocations per group), rather than accidentally submitting that many times
the required groups.

The hybrid executor now recognizes this exact ONNX form and uses it only
after an end-to-end CPU comparison for the exact batch/shape.  The comparison
includes H2D, dispatch, fence wait, D2H, and FP32 output validation; rejected
shapes continue through the AVX-512/AVX2/NEON/scalar CPU kernel with no output
change.  Vulkan smoke now validates an odd-size `N=3,Cin=5,Cout=7,11x13`
batch against scalar FP32 reference values, including its vector tail.

On the local AMD Radeon 780M, the FPN admission sample
(`N=4,Cin=32,Cout=40,31x29`) measured **2.48820 ms GPU / 0.60534 ms CPU**,
so it was correctly rejected rather than being presented as an OCR speedup.
The post-change five-size tiny hybrid batch-equivalence run remained exactly
serial-identical with **130** decoded results and measured
**1098.189 / 1079.664 ms** serial/batch (**1.017x**).  This is a real
mixed-size batch validation on this host, not a general GPU throughput claim.
`gpu_only` remains unavailable until the full detector and recognizer graphs
can stay device-resident.

### 2026-08-12: FPN transpose shared-filter GPU tile and multi-model batch gate

The Vulkan FPN transpose primitive now selects a shared-filter workgroup form
when its `[Cin,2,2]` row fits the 4,096-float local-memory budget.  A
workgroup stages the non-contiguous ONNX `[Cin,Cout,2,2]` row into contiguous
shared memory once, then computes a 1,024-pixel tile for one output channel.
The staging explicitly preserves the original increasing-input-channel FP32
reduction order.  Wider exported layers retain the generic batch kernel.  The
odd `N=3,Cin=5,Cout=7,11x13` Vulkan numerical test continues to compare every
result with scalar reference values.

On the local Radeon 780M, the complete-transfer FPN admission sample improved
from the preceding **2.48820 ms** to **2.15242 ms GPU**; CPU measured
**0.45748 ms**, so hybrid still correctly selects CPU for that isolated node.
This is intentional: hybrid uses Vulkan when the measured complete segment is
equal or faster, rather than increasing CPU offload at the cost of latency.

The five-size public hybrid batch gate (`16x16`, normal English,
low-contrast, `3000x80`, and dense `1920x1080`; recognizer batch 8, one
recognizer worker) remained serial-identical for all official models: small
**126** results (**2751.279 / 3384.936 ms**, **0.813x**) and medium **129**
results (**7358.610 / 7808.435 ms**, **0.942x**) in this shared-host sample;
tiny's same gate was **130** results (**1098.189 / 1079.664 ms**, **1.017x**).
The C++/ONNX Runtime medium decoded-text gate also passed **4/4** distinct
sizes/aspect ratios (`16x16`, English, low-contrast, wide strip).  The
repository's paired benchmark scripts now accept `-Model tiny|small|medium`,
and `bench/compare_models.ps1` runs all three across the same five-size corpus
for deployment-specific ORT comparison.  Mixed-size batching is not asserted
as a universal speedup; output equivalence and bounded work are the gate.

For a fresh paired single-page sanity sample after this GPU-tile change
(`en.ppm`, two warm-ups, five runs, 16-thread CPU budget, CPUExecutionProvider
for ONNX Runtime), all three official sizes remained faster than ORT:

| Model | C++ hybrid mean | ORT CPU mean | C++ improvement |
|---|---:|---:|---:|
| tiny | 95.490 ms | 128.475 ms | 25.67% |
| small | 157.035 ms | 270.218 ms | 41.89% |
| medium | 263.851 ms | 478.374 ms | 44.84% |

The host is shared and short-run tiny measurements have greater variance; the
table is current measured evidence, not a portable guarantee.  It uses the
same complete detector+recognizer OCR work in both implementations.

### 2026-08-12: terminal CTC guard and scalar-reference coverage

`RunCtcTop1()` already avoids materializing the terminal
`[N,T,6906]` Softmax activation: it keeps final logits, computes only CTC
top-1 indices and probabilities for emitted characters, then releases the
logits at function exit.  This revision narrows the fast-path eligibility to
a verified class-axis terminal Softmax (`axis=-1` or `axis=2`) on the official
`[N,T,V]` exports; a terminal Softmax over any other axis now fails fast rather
than silently applying CTC semantics to the wrong dimension.  The low-level
kernel smoke now compares SIMD-dispatched CTC against a scalar reference for
both a tail-heavy `N=3,T=17,V=31` case and production-width
`N=4,T=41,V=6906`, including blank and repeated-token paths.

Validation after the guard: the expanded CTC kernel smoke passed under both
default AVX-512 dispatch and forced AVX2; C++/ONNX Runtime decoded text passed
**4/4** diverse inputs for tiny and small, while the preceding medium gate was
also **4/4**.  The five-size tiny hybrid batch gate remained serial-identical
at **130** results (**1207.436 / 1297.085 ms**, **0.931x** on this shared
host). A medium five-size/two-cycle memory soak stayed bounded at a
**449,376,256-byte** post-warm-up baseline; cycles ended at **+7,770,112** and
**+5,087,232 bytes**, which is allocator high-water reuse rather than monotonic
per-cycle growth.  Radeon 780M Vulkan smoke remained numerically passing; its
full-transfer policy continued to select GPU only for shapes that measured no
slower than CPU.

### 2026-08-12: hybrid detector batch admission and benchmark controls

`RecognizeBatch()` now permits its existing exact-shape detector NCHW batches
when `Backend::hybrid` is selected as well as on CPU. This does not change
resize semantics or pad differently sized pages: pages are still grouped only
when their independently calculated detector width and height match exactly.
Every Vulkan operator continues to make a separate batch-shape admission
decision that includes H2D, dispatch, fence wait, D2H, and numerical
validation. A rejected operator uses its CPU SIMD batch kernel, so enabling a
larger detector batch never forces a slower partial-GPU path.

`ppocr_bench` now reads `PPOCR_DET_BATCH_SIZE`; `ppocr_batch_smoke` also
reports both effective detector and recognizer batch sizes (and accepts
`PPOCR_REC_WIDTH_BUCKET`). This makes the public batch path reproducible for
deployment A/B work.

On the local Radeon 780M system, eight equal `en.ppm` pages, one page worker,
`rec_batch_size=8`, and `det_batch_size=8` remained exactly serial-equivalent.
One fresh steady-state sample measured CPU **296.587 / 181.402 ms**
(**1.635x**) and hybrid **343.533 / 219.900 ms** (**1.562x**) for serial versus
batched execution. Hybrid with `det_batch_size=1` measured **274.675 /
232.065 ms** (**1.184x**) in a separate run, so this host benefited from
allowing the same-shape detector batch. These are host-specific measurements,
not a claim that every GPU or page mix will have the same ratio.

Regression coverage after the change: normal and AVX2-forced
`ppocr_kernel_smoke` passed; the Vulkan primitive smoke passed on AMD Radeon
780M; and decoded text matched ONNX Runtime for all four varied images in each
of tiny, small, and medium (**4/4 per model**). `gpu_only` remains explicitly
unavailable until the full detector and recognizer graph is device-resident.

### 2026-08-12: fused Vulkan FPN resize/add batch primitive

The FPN's graph-proven `Resize(nearest, 2x) -> Add(lateral)` sequence now has
a Vulkan `NCHW` batch primitive. It uploads the small source map and lateral
residual once, generates each nearest-neighbour value and sums it in one
shader dispatch, then reads only the completed result. The short-lived
expanded resize tensor is therefore never materialized on either CPU or GPU.
Odd dimensions and four-page batch addressing are covered by the Vulkan
smoke test.

Hybrid admission is shape-specific and strict: the measured path includes
source/residual H2D copies, shader dispatch, fence wait, D2H copy, and every
FP32 output comparison against `NearestResize2xAdd`. On this AMD Radeon 780M,
the representative `N=4,C=24,31x29` probe measured **0.47230 ms GPU** versus
**0.06686 ms CPU**, so it is correctly retained on AVX-512 CPU rather than
being forced onto the GPU. This primitive is nevertheless batch-ready for
hardware where the complete path wins.

Post-change validation: default and forced-AVX2 kernel smoke passed; Vulkan
smoke passed; tiny CPU and hybrid decoded-text comparison against ONNX Runtime
passed **4/4** varied inputs; and CPU tiny five-size/two-cycle memory soak
finished at **-139,264** and **-13,721,600 bytes** relative to a
**146,825,216-byte** post-warm-up baseline. A fresh eight-identical-page,
batch-8 smoke sample was exact-equivalent to serial: CPU **303.220 / 181.519
ms (1.670x)** and hybrid **336.976 / 213.733 ms (1.577x)**, serial/batched.
For a single `en.ppm` page with batch sizes one, CPU averaged **37.206 ms**;
hybrid averaged **37.649 ms**, so this shared host's current partial offload
does not claim a whole-pipeline GPU gain. `gpu_only` remains unavailable until
the entire detector and recognizer graphs are device-resident.

### 2026-08-12: recognizer CTC-path lifetime and Vulkan GEMM coverage

The production `RunCtcTop1()` recognizer executor now directly runs fused
`1x1 Conv + shortcut` nodes, matching the ordinary executor rather than
falling through its generic node path. This removes graph-input-vector setup
on the dense residual path and releases the source feature map immediately
after the fused kernel writes its destination. It is shared by tiny, small,
and medium; the three-model CPU/hybrid decoded-text regression against ONNX
Runtime remained **4/4 per model** over tiny, normal English, noisy
low-contrast, and ultra-wide input dimensions.

Vulkan additionally now implements row-major projection GEMM (`[R,K] x
[K,C] + bias`) for recognizer attention and CTC-head-compatible layouts. It
has a numerical smoke for odd `37x29x103` dimensions and a strict full-boundary
admission probe. The Radeon 780M measured the representative `64x128x512`
case at **0.67616 ms GPU** versus **0.15548 ms CPU**, so hybrid correctly keeps
this shape on CPU. The same smoke measured GPU wins for selected batch
depthwise and affine+Swish shapes, which hybrid admits automatically. This
keeps GPU work data-driven and prevents an isolated GPU primitive from
silently increasing complete-OCR latency.

The AVX-512 FPN resize/add kernel was also tightened to load one contiguous
16-float source vector per iteration before two indexed broadcasts; default
and forced-AVX2 kernel smoke pass. On a fresh 16-worker `en.ppm` run (three
warmups, ten timed runs), CPU means were **33.535 / 68.351 / 215.205 ms** and
hybrid means **32.155 / 76.156 / 258.877 ms** for tiny/small/medium. Current
paired ONNX Runtime means from the same session were **176.288 / 229.349 /
572.251 ms**, so CPU remains the deployment recommendation for small/medium
on this UMA GPU while retaining a large native-vs-ORT advantage.

A five-size tiny batch gate (`16x16`, English, low contrast, `3000x80`, dense
`1920x1080`; batch 8) returned all **130** results identically. This mixed
corpus measured **874.808 / 987.314 ms** CPU serial/batched and **1096.915 /
1107.025 ms** hybrid serial/batched, demonstrating that heterogeneous work is
not mislabeled as a throughput win. Its two-cycle memory soak stayed below its
**146,587,648-byte** post-warm-up baseline by **14,483,456** and
**14,401,536 bytes**. `gpu_only` remains explicit-unavailable until complete
detector and recognizer device residency is implemented and verified.

### 2026-08-12: CTC residual GPU admission and true page-batch validation

`RunCtcTop1()` is the production recognizer path, so its fused `1x1 Conv +
shortcut` blocks now use the same batched Vulkan admission path as the generic
executor.  This closes a policy gap where recognizer residual blocks could not
be considered for hybrid execution even when their exact NCHW batch shape had
already been measured.  The decision remains conservative and shape-local:
Vulkan is used only after the full input/residual upload, dispatch, fence wait,
readback, and CPU-SIMD numerical check are no slower than the CPU block.

The change was verified on AMD Radeon 780M with kernel SIMD smoke, Vulkan
primitive smoke, and identical decoded CPU OCR output. A four-page equal-size
tiny batch (`4 x en.ppm`, `det_batch=4`, `rec_batch=4`, one page-scheduler
worker) returned all eight text lines identically and measured:

| Backend | Serial pages | True NCHW page/crop batch | Speedup |
|---|---:|---:|---:|
| CPU | 148.554 ms | 91.244 ms | 1.628x |
| Hybrid | 138.904 ms | 94.528 ms | 1.469x |

This is a same-shape batching result, not a claim for arbitrarily mixed page
sizes. The existing scheduler still groups detector inputs only when their
native PP-OCR resize shape matches and buckets recognizer crops by padded
width, avoiding semantic changes from artificial image padding.

Fresh `en.ppm` end-to-end measurements (16 CPU workers, 3 warmups, 10 timed
runs) show the native engine remains faster than the paired CPU ONNX Runtime
baseline. These are host-specific AMD Radeon 780M / AVX-512-host measurements,
not portable guarantees:

| Model | C++ CPU | C++ hybrid | ORT CPU | CPU latency reduction vs ORT |
|---|---:|---:|---:|---:|
| tiny | 38.215 ms | 37.812 ms | 127.162 ms | 69.9% |
| small | 78.114 ms | 76.542 ms | 220.022 ms | 64.5% |
| medium | 220.072 ms | 240.608 ms | 487.076 ms | 54.8% |

The medium hybrid result is intentionally reported as slower than CPU. Its
individual Vulkan segments may still be admitted only where their complete
boundary beats SIMD; varying transfer/cache pressure on this shared UMA host
can make end-to-end hybrid slower. `gpu_only` still fails explicitly because
the entire PP-OCRv6 graph is not yet Vulkan-resident.

### 2026-08-12: default CPU worker budget tuned for PP-OCR batches

The persistent SIMD worker pool now defaults to **12** workers (still
overrideable with `PPOCR_BENCH_THREADS`). This is a measured scheduling/cache
decision, not a hardware-core-count assumption: on the local AVX-512 host,
the default PP-OCR graph's short detector/recognizer channel tiles saturated
useful memory bandwidth before 16 workers and the extra threads made all three
model sizes slower. The public crop scheduler default is aligned to the same
12-worker budget, avoiding nested page-level oversubscription.

On `en.ppm` with CPU-only execution, three warmups and eight timed runs, the
thread sweep measured the following mean end-to-end latency:

| Model | 8 workers | 12 workers (new default) | 16 workers |
|---|---:|---:|---:|
| tiny | 30.140 ms | 32.457 ms | 35.257 ms |
| small | 70.752 ms | 62.472 ms | 71.507 ms |
| medium | 226.918 ms | 215.528 ms | 226.332 ms |

Tiny stays fastest at eight workers on this host, while the new default gives
the best balanced small/medium result and avoids the former 16-worker
regression. Deployments optimizing only tiny can use
`PPOCR_BENCH_THREADS=8`; larger-server CPUs can continue to tune the existing
override.

Post-change validation covered default and forced-AVX2 kernel smoke, Radeon
780M Vulkan smoke, all three `en.ppm` models, and true NCHW batches. The
five-size corpus (`16x16`, English, low contrast, `3000x80`, dense
`1920x1080`) decoded **130** tiny-model results identically in CPU and hybrid
batch scheduling. Its CPU serial/batched timing was **446.898 / 408.895 ms**;
hybrid was **805.625 / 440.226 ms**. The two-cycle tiny memory soak over that
same five-size corpus ended **10,407,936** and **11,051,008 bytes below** its
128,106,496-byte post-warm-up baseline.

### 2026-08-12: fused Vulkan recognizer GEMM + Swish

The Vulkan recognizer projection primitive now has a `GEMM + Swish` mode for
the graph-fused MLP projection. It accepts the flattened rows of a real crop
batch, caches immutable weights/biases as before, and applies the exact Swish
while writing the GPU result. This removes the former complete CPU-side Swish
traversal after a successful hybrid GEMM dispatch. The shader path is covered
by an odd-tail `41x29x103` numerical smoke case and an end-to-end admission
probe against CPU SIMD `GEMM + Swish`; hybrid still uses it only when the full
upload, dispatch, fence, and readback time is no slower. This is additional
batch-aware GPU coverage, not a claim that the complete PP-OCR graph is yet
device-resident or that `gpu_only` is available.

Validation after the change passed the normal and forced-AVX2 kernel smoke
suites, plus the Radeon 780M Vulkan suite (including the new numerical
GEMM+Swish tail case). On that smoke run the complete-boundary GEMM+Swish
probe measured **0.65962 ms GPU vs 0.15050 ms CPU**, so the dynamic policy
correctly retained CPU for that transfer-bound shape. Tiny-model decoded-text
comparison against ONNX Runtime again passed **4/4** diverse inputs. Four
identical `en.ppm` pages also remained serial-equivalent: CPU measured
**151.283 / 103.396 ms (1.463x)** serial/batched, hybrid
**133.678 / 109.307 ms (1.223x)**. These are local samples; the stricter
per-segment admission rule remains the GPU performance authority.

### 2026-08-12: terminal CTC projection memory experiment

The recognizer executor now contains an optional experimental
`PPOCR_ENABLE_FUSED_TERMINAL_CTC=1` path that computes a terminal
`MatMul(+bias) -> Softmax -> CTC Top-1` directly from one reusable vocabulary
row buffer. It eliminates the transient `[N,T,V]` logits allocation and
preserves the dense projection's K-order plus exact selected-class Softmax
probability. It is deliberately opt-in: on the local AVX-512 CPU the scalar
vocabulary-row implementation is not a stable latency win for every official
model, although it is useful for memory-constrained deployments and passed
the text regression on the exercised corpus. The default continues to use the
proven SIMD GEMM plus vectorized CTC scan until a native SIMD fused terminal
kernel demonstrates a three-model speedup.

The row-buffer path is now covered in the SIMD kernel smoke with both a
small odd-tail projection and a `4x41x6906` recognizer-sized projection.
The portable regression corpus was also expanded beyond the original four
shapes: blank `800x600`, English and CJK single lines, a mixed three-line
receipt, and two-line CJK all decode with ONNX Runtime text parity for tiny,
small, and medium (**15/15 per model**). Deliberately adversarial rotation and
extreme portrait-strip images are retained as diagnostic samples, but are not
used as decoded-text parity gates because the two independently implemented
detector postprocessors can select different unstable low-confidence boxes.

### 2026-08-12: cooperative Vulkan GEMM tile and larger page batches

The Vulkan recognizer GEMM now has a cooperative **8-row 鑴?128-column** FP32
tile for ordinary (non-Swish) projections. Each workgroup stages a 16-wide K
slice of A and B, reusing B across eight rows rather than rereading it per
output element. The kernel keeps K tiles in ascending order, retains the
existing scalar-tail path, and is selected only after the existing exact
CPU-versus-full-boundary admission check. `gpu_only` remains unavailable: this
is a batch-aware primitive within the hybrid executor, not a device-resident
PP-OCR graph.

The new path is covered by Vulkan numerical smoke with a tail-heavy
`13鑴?7鑴?73` GEMM (rows, K, columns), in addition to the existing odd-tail and
GEMM+Swish cases. Normal SIMD smoke and Vulkan smoke passed on the local
AVX-512 / Radeon 780M host. Hybrid decoded-text parity against ONNX Runtime
again passed 4/4 diverse inputs for both tiny and medium (`16x16`, English,
low-contrast, and `3000鑴?0`).

For an eight-page same-shape `en.ppm` batch with `det_batch_size=8`,
`rec_batch_size=8`, and one recognizer scheduler worker, the post-change
hybrid measurements were tiny **304.188 / 225.182 ms (1.351x)** and medium
**2029.114 / 2019.849 ms (1.005x)** serial/batched. A four-shape hybrid batch
gate (`16x16`, English, low-contrast, `3000鑴?0`; batch sizes 4) remained
serial-identical for all models: tiny **186.390 / 176.957 ms (1.053x)**, small
**379.836 / 371.670 ms (1.022x)**, medium **1209.497 / 1215.288 ms (0.995x)**.
These are one host's steady-state samples, not a universal GPU claim; the
per-shape GPU admission continues to reject transfer-bound work.

After the latest pass, default CPU/hybrid batch regression again produced
serial-identical results across four different page shapes (`16x16`, English,
low-contrast, and `3000x80`). With bounded `det_batch_size=4` and
`rec_batch_size=4`, the local CPU/hybrid batch timings were tiny
**176.722/185.384** and **170.369/165.231 ms**; small **343.559/301.114** and
**374.170/293.868 ms**; medium **1317.190/1291.101** and
**1163.054/1122.104 ms**. A medium two-cycle varied-size memory soak started
at **495,898,624 bytes** after warm-up and ended **9,752,576** then
**10,174,464 bytes below** that baseline. These are host-local measurements,
not a general ONNX Runtime comparison claim.

### 2026-08-12: optional PP-OCRv6 vector GELU validation

The existing optional recognizer vector tanh-GELU path
(`PPOCR_APPROX_GELU=1`) was revalidated on AVX-512/AVX2; NEON/scalar retains
its portable fallback. This removes scalar `erf` from the MLP activation hot
path. The exact-Erf ONNX path remains the default, and the model-specific
vector path was checked against ONNX Runtime decoded text rather than being
assumed numerically interchangeable.

With 12 worker threads, three warmups and ten `en.ppm` runs, the scalar-Erf
baseline measured **29.097 / 60.268 / 202.201 ms** for tiny/small/medium; the
optional vector path measured **23.577 / 53.054 / 191.974 ms** in the same
session (**19.0% / 12.0% / 5.1%** lower mean latency). A longer shared-host
30-run medium sample was noisier, so the 10-run paired sweep is recorded as
an optimization signal, not a portable latency guarantee.

The decoded-text parity gate passed **4/4** diverse dimensions against ONNX
Runtime for each official model size (tiny, small, medium): `16x16`, English,
low-contrast, and `3000x80` ultra-wide. CPU and hybrid also produced identical
Chinese tiny-model text for the CJK sample. The kernel smoke still passes with
normal AVX-512 dispatch and forced AVX2 fallback.

### 2026-08-12: AVX-512 batch-GEMM dispatch refinement

The AVX-512 dense-GEMM path now selects its four-row by 64-column micro-kernel
per projection shape instead of applying its extra register pressure to every
recognizer tier. It stays enabled only for `K >= 384` (and can be disabled for
A/B with `PPOCR_DISABLE_AVX512_GEMM4ROW=1`); AVX-512 閳?AVX2 閳?scalar/NEON
runtime dispatch remains unchanged for all x86 and Arm targets. This keeps
large medium-model projections eligible to reuse each immutable B vector over
four output rows, while tiny/small use the lighter proven path.

Fresh `en.ppm` CPU measurements (three warm-ups, ten runs, 12 kernel workers)
were tiny **29.699 ms**, small **59.577 ms**, and medium **196.789 ms**. The
previous all-shape four-row experiment measured small **82.637 ms** and medium
**267.150 ms** in the same benchmark configuration, so the new admission
guard is retained. A dense `1920x1080` medium page (122 boxes,
`rec_batch_size=4`, `rec_parallelism=4`, one warm-up, three runs) measured
**4,496.430 ms** with the wide tile enabled and **4,426.272 ms** with it
disabled; therefore the dense-page default now avoids that tile whenever its
projection depth is below the measured `K=384` cutoff. These are
host-local figures, not an ONNX Runtime claim.

The normal AVX-512 kernel smoke passed after the change, as did the complete
Radeon 780M Vulkan smoke suite. The latter again verified all GPU batch
primitives numerically and dynamically admitted only full-boundary winners:
affine+Swish **0.17342 vs 0.34950 ms**, depthwise **0.34814 vs 0.47170 ms**,
depthwise+Swish **0.35624 vs 0.60330 ms**, and depthwise+HardSwish
**0.34528 vs 0.41760 ms** (GPU vs CPU). Transfer-bound GEMM and other
primitives stayed on CPU; `gpu_only` is still explicitly unavailable until
the complete PP-OCR graph is device-resident.

### 2026-08-12: diverse-size regression and preprocessing arithmetic reduction

The preprocessing resize path now folds PP-OCRv6's fixed input normalization
into precomputed per-channel affine coefficients. It keeps the existing
bilinear rounding, RGB-to-BGR layout, detector mean/std, and recognizer
`[-1,1]` arithmetic, while removing three per-pixel floating-point divisions
from detector and crop preparation. This applies to serial OCR and true
`[N,3,H,W]` detector/recognizer batches, without adding a temporary image
buffer or changing the x86 AVX-512/AVX2/scalar/NEON runtime dispatch.

The post-change ONNX Runtime decoded-text gate passed **8/8** diverse PPM
sizes for every official model (**24/24 total**): `16x16`, English, noisy
low-contrast, `3000x80`, English/CJK single lines, mixed text, and CJK. A
four-page CPU batch smoke across the smallest, normal, low-contrast, and
ultra-wide samples remained byte-for-byte result equivalent to serial OCR
and measured **190.614 / 176.096 ms (1.082x)** serial/batched for tiny.
This explicitly exercises multiple aspect ratios rather than using a
same-page-only batch claim.

A fresh `en.ppm` three-warmup/ten-run snapshot (12 kernel workers) measured
CPU tiny **35.073 ms**, small **72.582 ms**, medium **244.095 ms**; hybrid
measured **34.887 / 72.036 / 244.847 ms**. The hybrid implementation still
selects Vulkan only after per-shape numeric validation of the complete
upload, dispatch, fence, and readback boundary; therefore it may reduce CPU
work without claiming a universal latency gain on UMA hardware. `gpu_only`
remains an explicit failure until all PP-OCRv6 operators are device-resident.

The expanded five-size memory soak (`16x16`, English, low-contrast,
`3000x80`, dense `1920x1080`) was also run twice per model. It showed no
unbounded retained activation frontier: tiny ended **14.63 MiB below** its
146,534,400-byte warm baseline; small and medium ended **8.66 MiB** and
**11.69 MiB** above their 178,892,800-byte and 425,119,744-byte baselines.
Those modest Windows allocator deltas are reported rather than hidden; a
future allocator-pool change must improve this measured dense-page result
without weakening the 24-case text-parity gate.

### 2026-08-12: dense recognizer GEMM tile admission refinement

The medium dense-page operator profile identified transformer dense projection
as the largest recurring recognizer cost (`FusedMatMulBias` was **28.685 ms**
for one profiled crop batch), ahead of any scalar postprocessing. The AVX-512
four-row GEMM micro-kernel therefore now requires both `K >= 384` **and**
`N >= 384`. This keeps it on the PP-OCRv6 medium MLP expansion
`192x768` while retaining the lower-register-pressure two-row implementation
for the paired `768x192` projection. The runtime CPU hierarchy is unchanged:
AVX-512 is selected only after runtime CPUID/XCR0 checks, then AVX2/FMA,
then portable scalar/NEON.

On the dense `1920x1080` medium UI (122 boxes, `rec_batch_size=4`,
`rec_parallelism=8`, eight kernel workers, one warm-up/three runs), the
refined default measured **4,328.474 ms**; disabling the four-row tile for
A/B gave **5,303.048 ms** (with a 6,549 ms shared-host tail). On `en.ppm`,
the same model measured **210.125 ms** versus **210.604 ms** disabled across
three warmups/ten runs. The normal AVX-512 kernel smoke, all three models'
eight-shape ONNX Runtime decoded-text gates (**24/24**), the Radeon 780M
Vulkan batch smoke, and a varied-shape hybrid batch identity check all passed.
The hybrid check continues to admit Vulkan only after complete-boundary
validation; in this sample it selected affine+Swish and depthwise variants
where GPU was faster, while keeping transfer-bound work on CPU.

### 2026-08-12: GPU-aware NCHW batch benchmark controls

`ppocr_batch_smoke` now supports repeatable steady-state measurements through
`PPOCR_BATCH_WARMUP` and `PPOCR_BATCH_RUNS`. It still verifies that every
batched page result (text, confidence, axis-aligned box, and four-point box)
matches serial inference exactly, then reports mean and median serial/batch
times. This exercises the existing real `[N,3,H,W]` detector batches and
cross-page recognizer crop batches; it is not a scheduler-only benchmark.

On the local Radeon 780M / AVX-512 host, four identical `en.ppm` tiny pages
with `det_batch_size=4`, `rec_batch_size=4`, one outer worker, two warm-ups,
and five timed runs produced eight serial-identical results. CPU measured
**192.813 / 137.304 ms** serial/batched (**1.404x**); hybrid measured
**175.306 / 125.126 ms** (**1.401x**). The hybrid result remains governed by
per-shape full H2D + dispatch + fence + D2H validation, so a GPU segment is
used only when it measured no slower than SIMD CPU for that exact batch shape.

The same hybrid configuration, with two warm-ups and three timed runs, gave
small **330.788 / 308.714 ms** (**1.072x**) and medium **991.291 / 1061.823
ms** (**0.934x**) serial/batched. The medium result is intentionally retained:
on this shared UMA host, combining page/crop work can lose to cache pressure
and transfer-bound segments. Batch support therefore does not claim a
universal GPU gain, and `gpu_only` remains unavailable until the full graph is
device-resident.

The latest run also reconfirmed dynamic high-ISA dispatch. With 12 kernel
workers and three warm-ups/six `en.ppm` runs, shape-gated AVX-512 pointwise
eight-output tiling measured tiny/small/medium **35.979 / 76.015 / 252.816
ms**. Disabling only that tile via `PPOCR_DISABLE_AVX512_POINTWISE8=1`
measured **36.286 / 81.219 / 268.576 ms**. The tile remains limited to
`C_in >= 192`, `C_out >= 192`, and plane >= 256; AVX-512 selection is runtime
CPUID/XCR0-gated, followed by AVX2 and portable scalar/NEON fallbacks.

### 2026-08-12: repeatable batch, Vulkan, memory, and model-size regression

This pass kept the production CTC executor's terminal-logit memory mode
opt-in (`PPOCR_ENABLE_FUSED_TERMINAL_CTC=1`): it replaces a full terminal
`[N,T,V]` logits activation with a per-sequence row workspace, but remains
off by default because the regular SIMD GEMM path is faster on this host.
This preserves the lower peak-memory option without making an unmeasured
throughput trade-off the default.

The complete CPU-side five-size private-memory soak was rerun with 12 kernel
workers over `16x16`, English, low-contrast, ultra-wide `3000x80`, and dense
`1920x1080` inputs. After all shapes were warmed, tiny finished cycle two
**10.09 MiB below** its **126,599,168-byte** baseline. Small and medium one
post-warm cycles reported **+4.07 MiB** from **178,348,032 bytes** and
**+10.47 MiB** from **425,025,536 bytes** respectively. These allocator
deltas are reported as observed rather than treated as a leak verdict.

The decoded-text ONNX Runtime regression passed the full eight-shape corpus
for tiny and small (**8/8 each**), and the cross-model boundary subset
(`16x16`, English, low-contrast, `3000x80`) passed medium (**4/4**). The
Radeon 780M Vulkan primitive suite also passed numerical validation. In its
latest sample hybrid admitted affine+Swish (**0.18734 vs 0.37020 ms** GPU/CPU),
depthwise+Swish (**0.33626 vs 0.61096 ms**), and depthwise+HardSwish
(**0.31810 vs 0.34620 ms**); transfer-bound projection, GEMM, ordinary Conv,
and resize work stayed on CPU automatically.

Finally, a paired six-run medium English benchmark with two warm-ups and 12
kernel workers measured pure C++ CPU **259.037 ms** versus ONNX Runtime CPU
**297.913 ms** (**13.1% lower latency**, **3.860 vs 3.357 FPS**). The ORT
sample had shared-host variation, so this is a current reproducible snapshot,
not a universal multiplier.

### 2026-08-12: optional large-map SIMD GELU admission

`PPOCR_APPROX_GELU=1` now applies the PP-OCR-specific vector GELU
approximation only to tensors with at least 65,536 values. This avoids the
short, decode-sensitive boundary activations while allowing the AVX-512/AVX2
path to amortize its approximation on genuine large feature maps. Exact
Erf-GELU remains the default, and Arm/NEON remains on the portable exact path.

With 12 kernel workers, three warm-ups, and ten English-page runs, the gated
opt-in mode measured tiny/small/medium **27.295 / 53.594 / 204.034 ms**,
versus exact-default **28.491 / 61.181 / 214.164 ms** in the paired session:
**4.2% / 12.4% / 4.7%** lower latency. The opt-in decoded-text gate passed
tiny **8/8**, small **8/8**, and medium **4/4** across the same diverse
dimensions used above. A mixed-size hybrid page/crop batch also remained
serial-identical (four pages, seven results); it measured **161.524 /
164.530 ms** serial/batched on this heterogeneous mix, so no universal batch
speedup is claimed for unlike page shapes.

### 2026-08-12: Vulkan batch revalidation

After rebuilding the Vulkan batch path, the Radeon 780M primitive smoke test
again passed numerical validation. The complete-boundary policy kept the
transfer-bound binary, pointwise, depthwise, GEMM, ordinary-convolution and
resize probes on CPU; affine+Swish was the only selected GPU primitive in the
latest pass (**0.42584 vs 0.43290 ms** GPU/CPU). These are per-primitive
measurements including H2D, dispatch, fence and D2H, not a claim that the
whole OCR graph is GPU-resident.

On four same-shape `en.ppm` pages with hybrid selected, one page worker,
`det_batch_size=4`, `rec_batch_size=4`, one warm-up and three timed runs,
the serial/batched comparison was **148.272 / 115.169 ms** (**1.287x**).
The result check remained exact at the public OCR result level (text, box and
confidence). The scheduler sends the real `N=4` tensor to both the CPU SIMD
and Vulkan primitive batch dimensions; heterogeneous inputs remain governed
by the existing width/shape buckets instead of being padded arbitrarily.

### 2026-08-12: GPU batch-path cleanup and recheck

The unvalidated experimental pointwise-to-depthwise Vulkan chain was removed.
It had never been reachable from the hybrid executor and had previously failed
its numerical validation, so retaining it would have overstated device-resident
graph support. The production Vulkan shader now contains only smoke-tested
primitive modes. `gpu_only` therefore continues to reject execution explicitly;
the implementation must not silently fall back to CPU until the complete
PP-OCRv6 graph, DB post-processing, and CTC decode can remain on the device.

After the cleanup, the Radeon 780M Vulkan primitive smoke and AVX-512 kernel
smoke both passed. The same four-page tiny English batch (`det_batch_size=4`,
`rec_batch_size=4`, one outer worker, one warm-up, three timed runs) remained
serial-identical: CPU was **140.573 / 100.661 ms** serial/batched (**1.396x**),
and hybrid was **135.904 / 99.425 ms** (**1.367x**). A hybrid ONNX Runtime
text gate also passed **4/4** diverse tiny inputs (16x16, English,
low-contrast, and 3000x80 ultra-wide). These figures exercise the public
real-N detector and recognition batches; they do not claim a complete
GPU-resident inference path.

### 2026-08-12: fused approximate BatchNorm-GELU

When the existing opt-in `PPOCR_APPROX_GELU=1` mode is enabled, a large
fused BatchNorm-GELU group now performs its channel affine and AVX-512/AVX2
Pad鑼?GELU approximation in one vector pass. This removes the previous
per-plane affine write/read round trip. The normal exact-Erf path is unchanged;
non-x86/NEON builds also retain its exact behavior. Set
`PPOCR_DISABLE_FUSED_BN_GELU=1` only to reproduce the former two-pass
experimental implementation for A/B measurement.

On the local AVX-512 host with 12 worker threads, two warm-ups and six English
runs, the fused mode measured tiny **27.106 ms**, small **51.901 ms**, and
medium **225.597 ms**. The former two-pass opt-in path measured **27.241 / 
62.450 / 232.207 ms** respectively, a material small-model reduction and a
positive medium improvement in that paired session. Decoded-text regression
against ONNX Runtime passed the eight-size corpus for tiny, small, and medium
(**24/24** total): 16x16, English, low-contrast, ultra-wide, English/CJK
single-line, mixed text, and CJK. The broad requirement to outperform ONNX
Runtime on every model and workload remains a continuing target, not a claim
from this one host-local optimization sample.

### 2026-08-12: batch-invariant GELU admission correction

The optional SIMD GELU admission was tightened so batching cannot change a
page's numerical execution path. Generic GELU is now always exact, because it
has no NCHW shape information and a total-element threshold could make a
singleton crop use Erf while the same crop in a batch used the approximation.
The model-aware fused BatchNorm+GELU path continues to use its AVX-512/AVX2
one-pass approximation only when each NCHW plane is at least 65,536 elements;
this predicate is invariant to the leading batch dimension. Exact GELU remains
the default and ARM/NEON retains the exact fallback.

After the correction, kernel and Radeon 780M Vulkan smoke both passed. The
hybrid decoded-text ONNX Runtime gate passed **4/4** tiny diverse inputs
(16x16, English, low contrast, and 3000x80), with `PPOCR_APPROX_GELU=1`.
The public four-page `en.ppm` batch gate also restored exact serial/batch
results at `det_batch_size=4`, `rec_batch_size=4`, and one recognition worker:
**169.174 / 123.454 ms (1.370x)** for its three-run hybrid sample. A longer
ten-run local snapshot measured CPU **165.446 / 118.013 ms (1.402x)** and
hybrid **210.649 / 142.646 ms (1.477x)**. These shared-host figures are batch
throughput evidence, not an end-to-end GPU-only performance claim; hybrid
still admits only individually validated full-boundary Vulkan segments.

### 2026-08-12: MatMul write-only activation allocation

The constant-weight transformer MatMul path now allocates its destination with
`resize()` rather than value-initializing it to zero. `kernels::Gemm()` writes
every output element from its bias/zero accumulator, so the previous clear was
dead memory traffic before the SIMD or Vulkan attempt. This reduces activation
write bandwidth and allocator work for the recognizer's tall batch-folded
projections without changing the CPU, hybrid, or ARM/NEON fallback semantics.

Post-change kernel and Vulkan smoke passed, including the Radeon 780M
full-boundary admission checks. Hybrid decoded-text parity against ONNX Runtime
passed the eight-size corpus for every supported model (**24/24**): 16x16,
normal English, low contrast, 3000x80, English/CJK lines, mixed text, and CJK.
A separate eight-image mixed-aspect tiny hybrid batch check returned all 14
serial-identical OCR results at **264.126 / 256.614 ms (1.029x)**; this is a
diversity/correctness gate and is intentionally not represented as a universal
throughput claim.

For a current 12-worker, three-warmup/twenty-run `en.ppm` CPU comparison on
this shared host, the measured C++ / ONNX Runtime means were tiny **34.049 /
85.073 ms** (60.0% lower C++ latency), small **75.880 / 106.510 ms** (28.8%
lower), and medium **249.121 / 210.750 ms** (18.2% higher). The medium sample
does not satisfy the project performance target and is recorded explicitly:
the remaining work is medium recognizer/detector optimization and longer
device-resident Vulkan segments, not a claim that this pass has already made
all models faster than ONNX Runtime.

### 2026-08-12: multi-adapter Vulkan selection for batched hybrid execution

The Vulkan backend now evaluates all compute-capable adapters instead of
blindly selecting Vulkan's first enumerated queue. Its default selection is
the integrated/UMA adapter, which is the appropriate default for the current
per-segment H2D/dispatch/D2H hybrid design; set
`PPOCR_VULKAN_PREFER_DISCRETE=1` to prefer a discrete accelerator. Deployment
integration can pin an adapter with `PPOCR_VULKAN_DEVICE_INDEX=N` or select it
by substring through `PPOCR_VULKAN_DEVICE_NAME=...`. CPU Vulkan drivers are
not chosen automatically, but may still be requested by index for diagnostic
purposes. Every selected operator remains gated by its exact shape/batch,
full-boundary no-slower-than-CPU measurement.

After this change, the Radeon 780M Vulkan smoke suite and AVX-512 kernel smoke
both passed. A four-page same-shape tiny batch (`det_batch_size=4`,
`rec_batch_size=4`, hybrid, one page worker, two warmups/five timed runs)
returned all eight public OCR results identically. The shared Windows host
showed unstable timing in the immediate post-build sample (**170.452 ms serial
/ 219.688 ms batch; batch median 119.245 ms**), so no new throughput claim is
made from that run. It nevertheless validates real `[N,3,H,W]` detector and
crop batches on the selected GPU path; it does not represent a GPU-only claim
because the complete graph, DB post-processing, and CTC decode are still not
device-resident.

### 2026-08-12: GPU batch front-end parallelism

The public batched API now exposes `Options::batch_preprocess_parallelism`
(default **4**), with the benchmark override
`PPOCR_BATCH_PREPROCESS_PARALLELISM`. For a same-shape detector batch, each
page's resize/BGR-normalize write owns a separate contiguous NCHW plane and is
prepared concurrently before the one batched CPU/Vulkan graph submission.
The budget is divided across concurrent dynamic-shape detector batches, so
raising `image_batch_parallelism` does not cause unbounded nested-thread
oversubscription. It is CPU front-end work that enables GPU/SIMD batching; it
does not change the strict Vulkan transfer/admission policy or imply a
GPU-only graph.

On the local Radeon 780M / AVX-512 host with the tiny model, four identical
`en.ppm` pages, `det_batch_size=4`, `rec_batch_size=4`, one page worker,
`PPOCR_APPROX_GELU=1`, three warm-ups, and ten timed hybrid runs, the
serial-identical public result check passed in both configurations. Serial
preprocess (`PPOCR_BATCH_PREPROCESS_PARALLELISM=1`) measured **121.887 ms**
batched mean (**1.479x** against **180.328 ms** serial); the default four-way
front end measured **119.919 ms** (**1.498x** against **179.646 ms** serial).
This is a **1.6%** improvement in that controlled local batch sample. Timing
on the shared Windows host remains variable, so the README records it as a
reproducible configuration-specific result rather than a universal GPU gain.

### 2026-08-12: experimental Vulkan tiled GEMM+Swish batch kernel

The Vulkan shader now includes an 8-row x 128-column cooperative GEMM tile
with Swish fused into its final writeback (mode 25). It shares a 16x128 weight
tile across eight flattened recognition rows, so it is designed for real
same-width crop batches rather than per-crop dispatches. Its FP32 K reduction
remains ascending, and the shader stays behind the existing numerical smoke
and complete H2D + dispatch + fence + D2H admission checks. Enable it only for
driver-specific A/B work with `PPOCR_ENABLE_VULKAN_GEMM_SWISH_TILE=1`; the
plain tiled GEMM path remains dynamically selected as before.

On the local Radeon 780M, AVX-512 host, the experimental tile passed kernel
and Vulkan primitive smoke plus the hybrid ONNX Runtime decoded-text gates for
tiny and medium (4/4 diverse inputs each). A quick medium four-page A/B saw
the tile at **1004.444 ms** batched mean and the default at **1041.713 ms**;
the longer shared-host samples varied enough that neither result is promoted
to the default. The default public medium batch remained result-identical and
measured **1178.757 / 1061.702 ms** serial/batched (**1.110x**) with two
warm-ups and six timed runs. This is an implementation and correctness
milestone, not a claim of a universal GPU speedup; hybrid continues to select
GPU only for primitives that win their exact full-boundary admission
measurement.

### 2026-08-12: recognition-batch front-end parallelism

`batch_preprocess_parallelism` now also prepares same-width recognition crops
in parallel. Each resize owns one already-zeroed, contiguous `[N,3,48,W]`
plane; output order, natural resize width, right padding, and normalization
arithmetic are unchanged. The front-end budget is divided by concurrent
recognizer batches, avoiding nested oversubscription when
`rec_parallelism > 1`.

On the local Radeon 780M / AVX-512 host, four same-shape tiny English pages
with hybrid mode, `det_batch_size=4`, `rec_batch_size=4`, one recognizer
worker, two warm-ups and eight timed runs were public-result identical. A
serial front end measured **112.023 ms** batch mean; four-way front-end work
measured **105.894 ms**, a **5.5%** batch-latency reduction. The corresponding
serial/batch speedups were **1.523x / 1.577x**. A five-run small-model check
remained result-identical too (**314.876 / 313.329 ms** batch at one/four-way
preprocess); it is kept as evidence that the gain is input/model dependent,
not as a universal throughput claim. Kernel and Vulkan primitive smoke passed
after the change; decoded-text ONNX Runtime checks also passed the small
model's 16x16, English, low-contrast and ultra-wide inputs. Very dense/tall
synthetic pages remain a deliberately stricter diagnostic corpus: their
near-threshold DB boxes can differ from ORT by one pixel and therefore must
not be used as a text-parity gate without a geometric tolerance.

### 2026-08-12: GPU-ready single-page crop batching

The same crop-plane parallelism is now used by both public entry points:
`RecognizeBatch()` and ordinary `Recognize()`. A dense single page can contain
several same-width recognition crops, so this closes a scheduling gap where
only multi-page batches could prepare their real `[N,3,48,W]` input planes in
parallel. The budget is `Options::batch_preprocess_parallelism` (or
`PPOCR_BATCH_PREPROCESS_PARALLELISM`) and is divided by active recognizer
batches, which prevents nested CPU oversubscription. Each worker owns a
pre-zeroed NCHW plane; width padding and every pixel/normalization calculation
remain unchanged.

This benefits the existing CPU SIMD and Vulkan hybrid paths equally. Vulkan
continues to receive a genuine NCHW batch, with its batch dimension mapped to
the shader dispatch Y dimension. It still offloads only an operator after its
same-shape, full H2D + dispatch + fence + D2H numerical/performance admission
test is no slower than the CPU kernel; `gpu_only` remains unavailable because
the complete PP-OCRv6 graph, DB postprocessing, and CTC decode are not
device-resident.

Post-change verification passed the AVX-512 kernel smoke, Vulkan primitive
smoke, four-page public result identity, and a medium varied-shape hybrid
memory soak. On the local Radeon 780M / AVX-512 host, four equal `en.ppm`
tiny pages in hybrid mode (`det_batch_size=4`, `rec_batch_size=4`, one page
and recognizer worker, two warm-ups, six timed runs) measured **117.702 ms**
with serial front-end work and **110.992 ms** with a four-way front end: a
**5.7%** batch-latency improvement (serial/batch speedup **1.420x ->
1.498x**). A short medium CPU batch check also preserved all eight public OCR
results and measured **1118.404 / 1021.506 ms** serial/batched (**1.095x**).
These shared-host figures are configuration-specific benchmarks, not a claim
that every model or GPU segment is faster.

### 2026-08-12: experimental AVX-512 wide-context tile

Medium PP-OCRv6 detector context blocks include padded 5x5 and 7x7
convolutions. An experimental AVX-512 eight-output tile now shares each
16-float input load across eight output channels, while keeping the existing
four-output implementation for a non-multiple-of-eight tail. It preserves
each output's increasing input/channel/kernel FMA order and has no effect on
AVX2, ARM/NEON, or scalar dispatch. Enable it only for deployment A/B work
with `PPOCR_ENABLE_AVX512_CONV_WIDE8=1`; the established four-channel tile
remains the default until it wins reliably across target CPUs.

Both default and opt-in paths passed the kernel smoke, including padded 5x5
and 7x7 eight-channel bodies plus nine-channel tails, and the full Radeon
780M Vulkan primitive suite. On this shared AVX-512 host, a medium `en.ppm`
CPU sample (two warm-ups/eight runs, twelve workers) measured **223.342 ms**
default and **221.962 ms** opt-in (0.6% lower mean). A 122-crop
`ui_dense_1920x1080` sample did not reproduce that gain (**4053.814 vs
4075.517 ms**, two warm-ups/five runs), so this remains deliberately opt-in
rather than a broad performance claim. Hybrid Vulkan admission remains
unchanged: every GPU primitive is still selected only when its validated full
H2D + dispatch + fence + D2H boundary is no slower than CPU.

The same post-change CPU 12-worker `en.ppm` snapshot (two warm-ups/ten runs)
was tiny **36.902 ms**, small **72.035 ms**, and medium **272.094 ms**.
Hybrid runs (two warm-ups/six runs) were **37.502**, **72.662**, and
**255.454 ms** respectively. The medium hybrid improvement is useful on this
UMA GPU, while CPU remains slightly better for tiny/small in this run; the
per-primitive admission rule intentionally preserves that outcome instead of
forcing Vulkan. Medium decoded-text parity against ONNX Runtime also remained
**4/4** across 16x16, English, low-contrast, and 3000x80 inputs with the
experimental wide tile enabled. These measurements do not change the prior,
more representative ONNX Runtime comparison: medium has not yet demonstrated
a consistent end-to-end lead over ORT and remains the main optimization target.

### 2026-08-12: fused GPU ordinary-Conv activation batches

The hybrid Vulkan ordinary NCHW convolution primitive now also accepts
graph-fused **Swish**, Sigmoid, and HardSwish writebacks. Non-pointwise
detector/recognizer Conv activation chains therefore use one batched GPU
submission, with no GPU-to-CPU readback merely to apply the nonlinear pass.
The CPU SIMD fallback is unchanged. Admission remains exact per
`(N,C,M,H,W,kernel,stride,padding,activation)` and includes H2D, dispatch,
fence, D2H, and output validation against CPU Conv plus the same activation.
If this complete boundary loses, hybrid keeps CPU; `gpu_only` remains
unavailable.

`ppocr_vulkan_smoke` now prints an independent `Conv+Swish` batch admission
measurement next to its existing `Conv+ReLU` result. This is primitive-level
evidence only; an end-to-end OCR GPU claim requires the corresponding shapes
to pass their dynamic admission measurements.

Post-change AVX-512 kernel smoke and Radeon 780M Vulkan smoke both passed.
The new ordinary `N=4,C=24,M=40,31x29,3x3` Swish probe measured **3.58512 ms
GPU vs 1.24636 ms CPU**, so hybrid correctly retained CPU for that segment on
this UMA device. A hybrid four-page exact-shape batch regression also remained
result-identical: tiny measured **109.844 / 84.810 ms** serial/batched
(**1.295x**), and medium **920.012 / 836.339 ms** (**1.100x**) with two
warm-ups and three timed runs, `det_batch_size=4`, `rec_batch_size=4`, and
four-way preprocessing. Medium decoded-text ONNX Runtime parity passed **4/4**
for 16x16, English, low-contrast, and ultra-wide inputs. These are controlled
batch measurements on a shared host, not a GPU-only or universal throughput
claim.

### 2026-08-12: liveness-aware in-place Concat

Both graph executors now reuse the first dynamic input of a final-use ONNX
`Concat` as the output storage. The general implementation handles every
legal axis: after growing the vector, it moves the first input's outer blocks
backwards (overlap-safe) and copies only the additional branch spans. This is
especially relevant to the medium detector's channel-axis FPN assembly, where
operator profiling previously exposed `Concat` as a measurable cost. It avoids
one complete output allocation and the copy of the first branch while keeping
the generic path for shared/aliased/non-final-use inputs. `RunCtcTop1()` has
the same rule, so public recognizer batches do not diverge from `Run()`.

Verification after the change passed AVX-512 kernel smoke, Radeon 780M Vulkan
smoke, and medium CPU decoded-text ONNX Runtime parity on 16x16, English,
low-contrast, and 3000x80 inputs (**4/4**). A medium hybrid seven-size memory
soak (16x16, English, low contrast, ultra-wide, ultra-tall, dense 1920x1080,
and 2560x1440 screenshot) finished one cycle at **+14,647,296 bytes** over a
453,398,528-byte post-warmup private-byte baseline. This is allocator
high-water behavior, not a leak assertion. The immediate six-run medium
`en.ppm` CPU sample measured **234.826 ms**; hybrid measured **258.733 ms** on
this shared UMA host, so the dynamic per-segment rule correctly does not claim
a blanket GPU gain.

### 2026-08-12: hybrid GPU batching and queue-aware scheduling

The Vulkan path continues to accept true detector and recognition NCHW
batches, and every implemented primitive uses the leading `N` dimension as
one dispatch dimension. This includes pointwise/residual, depthwise and
ordinary Conv, ConvTranspose, resize+Add, channel-affine, binary chains, and
recognizer GEMM. Immutable model weights/biases remain in the persistent
Vulkan context when an admitted segment repeats; dynamic images and residuals
are uploaded once per complete batch. The runtime restores compact descriptor
views before every dispatch, preventing a preceding cached parameter shape
from affecting a later batched operator.

Hybrid execution has one synchronized Vulkan queue, so parallel host graph
batches cannot run device work concurrently. `Options::hybrid_graph_parallelism`
therefore defaults to **1** (benchmark override
`PPOCR_HYBRID_GRAPH_PARALLELISM`), avoiding serialized submissions together
with multiplied CPU activation workspaces. CPU-only keeps
`rec_parallelism` independent batches in flight. This is a scheduling and
memory-peak safeguard, not a restriction on the tensor batch itself; use a
positive override only after measuring the target driver.

After the change, the AVX-512 kernel smoke and Radeon 780M Vulkan primitive
smoke both passed. On four same-shape tiny `en.ppm` pages with hybrid mode,
`det_batch_size=4`, `rec_batch_size=4`, four-way preprocessing, one warm-up,
and three timed runs, public OCR results were serial-identical. The queue-aware
default measured **150.969 / 105.663 ms** serial/batched (**1.429x**). An
explicit four-graph-worker A/B measured **131.838 / 102.749 ms** (**1.283x**)
on the same shared host. CPU-only under the same batch settings measured
**133.062 / 98.406 ms** (**1.352x**). These short, shared-host snapshots
demonstrate correct batch scheduling; they do not alter the strict
per-primitive GPU admission policy, do not claim universal GPU speedups, and
do not make `gpu_only` available.

### 2026-08-12: refreshed three-model and varied-size baseline

`ppocr_mem_soak` now accepts the same backend and bounded-batch environment
settings as the benchmark (`PPOCR_BACKEND`, detector/recognition batch sizes,
preprocessing, and hybrid graph parallelism). This makes the memory check
cover the production CPU/hybrid scheduler rather than always constructing a
default OCR instance.

With `PPOCR_APPROX_GELU=1`, CPU mode, two warm-ups and eight timed `en.ppm`
runs on this AVX-512 host, current C++ means were tiny **28.602 ms**, small
**58.717 ms**, and medium **206.668 ms**. Hybrid on the same short workload
measured **32.243 / 70.071 / 259.296 ms** respectively, so CPU was correctly
retained for this particular small-map run when Vulkan segment admission did
not improve the full OCR boundary. The earlier representative ORT comparison
still establishes a lead for tiny/small; medium remains an active optimization
target and is not claimed universally ahead of ONNX Runtime.

A medium hybrid varied-size one-cycle soak with seven samples (16x16,
English, low-contrast, ultra-wide, ultra-tall, dense 1920x1080, and
2560x1440 screenshot), `det_batch_size=4`, `rec_batch_size=4`, and four-way
preprocessing finished at **+2,134,016 bytes** over a
**436,551,680-byte** post-warmup private-byte baseline. This is a process
allocator high-water snapshot, not a leak proof; it demonstrates the current
test corpus and bounded activation behavior across materially different input
dimensions.

### 2026-08-12: queue-aware detector batching

`RecognizeBatch()` now applies the same queue-aware graph scheduling rule to
the detector as it already applied to recognition. `image_batch_parallelism`
still controls independent detector graphs in CPU mode. In hybrid mode, the
default is instead `hybrid_graph_parallelism=1`: one persistent synchronous
Vulkan queue cannot execute competing detector graphs concurrently, and
running several of them only retains several large detector activation
frontiers while their GPU submissions serialize. This does not reduce the
real tensor batch: same-resize pages still form bounded `[N,3,H,W]` detector
batches and all implemented Vulkan kernels map that N dimension to one
dispatch. Set `PPOCR_HYBRID_GRAPH_PARALLELISM` above one only after a
driver-specific A/B measurement.

Post-change AVX-512 kernel and Radeon 780M Vulkan primitive smoke both
passed. Four identical `en.ppm` pages, `det_batch_size=4`,
`rec_batch_size=4`, four-way preprocessing, two warm-ups and five timed runs
were serial-result-identical. With the hybrid default, tiny measured
**147.010 / 107.388 ms** serial/batched (**1.369x**) and medium measured
**1050.363 / 1026.150 ms** (**1.024x**). The matching CPU-only measurements
were **136.004 / 105.275 ms** (**1.292x**) for tiny and **994.335 / 976.100
ms** (**1.019x**) for medium. An explicit hybrid four-graph-worker experiment
was not a win in this sample: tiny batched latency rose to **158.929 ms**;
medium rose to **1096.940 ms**. A four-image varied-size medium hybrid smoke
also stayed serial-result-identical at **1242.143 / 1205.323 ms** (**1.031x**).
These shared-host measurements validate the scheduler and batch correctness;
they do not claim a universal GPU advantage. `gpu_only` remains unavailable
until the full PP-OCRv6 graph and post-processing are device-resident.

### 2026-08-12: medium CPU parallelism retune

The persistent CPU kernel executor's automatic ceiling is now **16** workers
(bounded by available hardware); `PPOCR_BENCH_THREADS` remains the explicit
deployment override. The previous automatic ceiling of 12 left measurable
medium-detector channel/tile parallelism unused on this AVX-512 host. Tiny and
small keep their short-kernel thresholds, so this is not a promise that every
model launches sixteen workers.

On the local AVX-512 host with `PPOCR_APPROX_GELU=1`, two warm-ups and twelve
timed `en.ppm` runs, the default CPU path measured tiny **28.124 ms**, small
**61.297 ms**, and medium **188.145 ms**. A medium 3000x80 strip measured
**130.692 ms** over eight runs. The controlled medium A/B was 12 workers:
**215.234 ms** mean, 16 workers: **189.517 ms** mean (both twelve-run
samples); 20 and 24 workers regressed, so the automatic cap is deliberately
16 rather than unbounded. The current same-host ORT eight-run `en.ppm`
snapshot is tiny **74.609 ms**, small **86.288 ms**, and medium **147.779
ms**: tiny/small retain clear native wins, while medium remains slower than
ORT on that comparison and is not claimed as meeting the final target.

The latest Radeon 780M Vulkan primitive suite still passed. Its full-boundary
admission selected GPU for the Swish channel-affine and depthwise-Swish batch
shapes, while ordinary Conv, pointwise Conv, GEMM and resize/add samples
remained transfer-bound and correctly retained CPU. A medium hybrid `en.ppm`
sample was **295.677 ms** (eight runs), versus the CPU result above, confirming
that a device-resident multi-operator graph segment閳ユ攺ot forced standalone
dispatches閳ユ攰s required before claiming a medium GPU end-to-end win.

### 2026-08-12: N=8 GPU-aware page batch and PPM stress gate

The public batch route was rechecked with eight identical tiny `en.ppm`
pages. It forms an exact `[8,3,H,W]` detector tensor and packs compatible
recognition crops into `[N,3,48,W]`; no page or crop is resampled merely to
fill a batch. Vulkan maps that leading N dimension to one compute-dispatch
dimension for each implemented hybrid primitive. With 16 CPU kernel workers,
`det_batch_size=8`, `rec_batch_size=8`, eight-way preprocessing, one graph
submitter, two warm-ups and eight timed runs, serial results and batch results
were exactly identical (16 decoded OCR results):

| Backend | Serial mean | N=8 batch mean | Batch speedup |
|---|---:|---:|---:|
| CPU | 337.102 ms | 233.977 ms | 1.441x |
| Hybrid Vulkan | 454.287 ms | 239.397 ms | 1.898x |

This is a same-host batch scheduling measurement, not a claim that the
partial Vulkan graph makes whole-image OCR faster than CPU on the Radeon 780M:
the hybrid N=8 mean was still 2.3% above the CPU N=8 mean. It does verify that
Vulkan-enabled batching is a real single-NCHW submission path with correct
output, rather than eight independent GPU calls.

### 2026-08-13: front-end address reduction and expanded recovery check

The fused RGB bilinear-resize/NCHW-normalization front end now hoists its two
source-row bases out of the destination-pixel loop.  This removes four
row/column address multiply-add chains per output pixel, without changing the
four source samples, interpolation order, integer rounding, or model input.
It applies to both detector-page resize and recognizer-crop resize paths, so
the benefit is architecture-neutral and composes with the existing AVX2,
AVX-512, and NEON graph kernels.

The change passed the complete low-level SIMD smoke suite and decoded-text
comparison with ONNX Runtime for all model sizes: tiny, small, and medium each
passed **4/4** inputs (`16x16`, English two-line, low-contrast text, and an
ultra-wide `3000x80` strip), for **12/12** total.  The wider robustness corpus
also passed **11/11** cases for tiny and small: blank, word, rotated text,
low-contrast text, wide/tall strips, dense blobs, dense UI, and 1920x1080 /
2560x1440 screenshots.  Medium passes the same semantic corpus except its
current detector threshold produces extra low-score components on the blank
and dense-blob synthetic cases; this is tracked as DB-postprocess tuning work,
not hidden as a performance success.

A fresh exact `N=4` CPU batch recheck (`det_batch_size=4`,
`rec_batch_size=4`, four-way preprocessing, one warm-up, five timed runs)
kept all eight decoded outputs serial-identical.  Mean batch speedups on this
shared AVX-512 Windows host were tiny **1.490x**, small **1.129x**, and medium
**1.243x**.  The medium value has visibly variable shared-host samples, so
these figures are evidence of the batched code path rather than portable
capacity guarantees.

The expanded `16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 -> 1280x720
-> 1920x1080 -> 2560x1440 -> 64x64` memory ladder was rerun for medium.  CPU
passed two cycles from a 146,903,040-byte warmed private baseline and returned
to 143,212,544 bytes (-2.51%) and 144,183,296 bytes (-1.85%); private bytes
and working set both declined after the largest image in both cycles.  Hybrid
Vulkan also passed: its 392,998,912-byte baseline returned to 393,195,520
bytes (+0.050%) in both cycles.  Hybrid private bytes remained 0.0031% above
the immediately preceding largest sample while working set declined, which is
expected persistent Vulkan/Windows allocator capacity rather than retained
image or activation memory.

### 2026-08-13: selective SIMD GELU dispatch

The opt-in `PPOCR_APPROX_GELU=1` path now reaches independent generic
`FusedGelu` activations as well as the existing fused BatchNorm+GELU route.
On x86 it dynamically selects AVX-512 first, then AVX2; the baseline exact
Erf implementation and ARM/NEON fallback remain unchanged.  The approximate
Pad鑼?tanh polynomial is intentionally limited to broad activations of at
least 262,144 elements.  That preserves the established exact path for the
short, decision-sensitive tiny/small recognizer tensors while accelerating
the large medium feature maps. `PPOCR_DISABLE_APPROX_GELU_SIMD=1` is a direct
deployment A/B escape hatch.

The AVX2 generic GELU kernel was also made genuinely vectorized: it no longer
stores each vector and calls scalar `tanh` eight times. AVX2 and AVX-512 now
use the same bounded Pad鑼?approximation for vector bodies and scalar tails.
The low-level smoke verifies separate and in-place large/tail GELU buffers,
and passed in both approximate and default exact modes.

With 16 workers on the local AVX-512 host, a paired medium CPU `en.ppm` A/B
(two warm-ups, eight timed runs) improved from **216.867 ms** with the new
generic SIMD route disabled to **205.715 ms** enabled (**5.1% lower** mean
latency).  Tiny, small and medium each again passed all four decoded-text
comparisons against ONNX Runtime (`16x16`, English, low contrast and
`3000x80`), **12/12** total.  The same-host 12-run CPU snapshot after the
change was tiny **34.335 ms** and small **75.072 ms**; shared-host variance
means these are compatibility snapshots, not portable throughput guarantees.

### 2026-08-13: SIMD terminal-CTC memory route

`PPOCR_ENABLE_FUSED_TERMINAL_CTC=1` now computes each reusable terminal-logit
row through the normal runtime-dispatched GEMM kernel instead of a separate
scalar `K鑴砎` loop. It still avoids materializing the full terminal `[N,T,V]`
logits tensor, but now uses AVX-512, AVX2, or ARM/NEON GEMM as available and
uses the existing ISA argmax. The K-order, selected-class Softmax calculation,
blank/repeat CTC recurrence, and output confidence remain unchanged.

With this opt-in mode and 16 CPU workers, all three models passed the four
diverse ONNX Runtime decoded-text inputs (**12/12**). The new N=4 public batch
smoke was serial-result-identical and measured **1.367x** (tiny), **1.149x**
(small), and **1.188x** (medium) batch speedup on this shared AVX-512 Windows
host. Two warm-ups/eight English-page runs measured **35.933 / 74.952 /
246.148 ms** for tiny/small/medium. The medium two-cycle
`16x16 閳?閳?閳?2560x1440 閳?64x64` CPU memory ladder also passed: a
**147,066,880-byte** warmed baseline returned to **143,347,712 bytes**
(-2.53%) and **147,116,032 bytes** (+0.03%), both below their pre-return
cycle high-water marks. The regular full-terminal-logits SIMD route remains
the default; this stays an explicit memory/performance deployment option.

### 2026-08-13: four-row terminal-CTC GEMM tile

The optional terminal-CTC route now projects up to four adjacent time steps
into its bounded vocabulary workspace at once, then performs the CTC scan in
the original time order. This keeps memory bounded to `4 鑴?vocab` values per
active sequence rather than `[N,T,V]`, while allowing the AVX-512/AVX2 GEMM
microkernels to reuse immutable projection weights across rows. The final
partial tile and every blank/repeat transition retain the same semantics.

On the 16-worker AVX-512 host, two warm-ups/eight `en.ppm` runs with
`PPOCR_ENABLE_FUSED_TERMINAL_CTC=1` measured **32.647 / 70.079 / 226.250 ms**
for tiny/small/medium. Compared with the preceding one-row fused-CTC sample,
this is **9.1% / 6.5% / 8.1%** lower latency. The post-change N=4 CPU smoke
remained serial-result-identical for all models and measured **1.350x**,
**1.201x**, and **1.195x** batch speedup respectively. The low-level kernel
smoke, all three four-image ONNX Runtime decoded-text comparisons (**12/12**),
and Radeon 780M Vulkan primitive/admission smoke passed. As intended, hybrid
continues to select GPU only for shapes that win the full transfer boundary;
the terminal CTC tile is a CPU-memory optimization, not a GPU-only path.

### 2026-08-13: four-row terminal-CTC resolution-ladder memory recheck

The deterministic `16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 ->
1280x720 -> 1920x1080 -> 2560x1440 -> 64x64` ladder was rerun after the
four-row terminal-CTC tile, with `PPOCR_BENCH_THREADS=16`,
`PPOCR_APPROX_GELU=1`, and `PPOCR_ENABLE_FUSED_TERMINAL_CTC=1`. The CPU
medium model passed the two-cycle bounded-recovery gate. Its warmed private
baseline was **143,339,520 bytes**; the post-large `64x64` samples were
**148,660,224 bytes** (**+3.71%**) and **147,742,720 bytes** (**+3.07%**).
They were only **+0.68%** above the immediately preceding `2560x1440`
sample in each cycle, well below the 20% gate.

In this particular shared-Windows-host run, neither private bytes nor working
set immediately declined after the largest page: the allocator retained or
reused capacity, rather than keeping the RGB image or activation objects
alive. The checker records this explicitly as `declined_after_largest=false`
and retains every per-resolution private-byte/working-set sample in
`build/memory_ladder_medium_fused_ctc_tile4_cpu_20260813.json`; it therefore
does not mislabel stable allocator capacity as immediate memory release. The
completed image is destroyed before every sample, and the bounded-recovery
pass is the portable regression condition.

### 2026-08-13: AVX-512 reconstruction 2x2 four-output default

The CPU dispatcher now enables the existing AVX-512 four-output tile for
valid `2x2` reconstruction convolutions by default when the shape has at
least eight input channels. It reuses each 16-float input vector across four
output filters while retaining the same per-output reduction order, scalar
tail, AVX2, NEON, and baseline fallbacks. This covers the tiny/small/medium
detector reconstruction pairs (`8閳?6`, `12閳?4`, and `32閳?4` channels) without
introducing an ISA requirement. Set `PPOCR_DISABLE_AVX512_CONV2X2_TILE4=1`
for a deployment A/B fallback.

On the local shared AVX-512 Windows host (`PPOCR_BENCH_THREADS=16`, opt-in
approximate GELU and four-row terminal CTC), the medium English page improved
from **237.935 ms** to **230.035 ms** across 16 timed runs (**3.3% lower**
mean latency). A two-run dense `1920x1080` sample also reduced from
**4,740.695 ms** to **4,208.679 ms** (**11.2% lower**); this dense figure is
intentionally short and host-variable, so it is directional rather than a
portable throughput guarantee. A fresh 2-warmup/8-run CPU snapshot measured
tiny **35.970 ms**, small **79.078 ms**, and medium **235.396 ms** on `en.ppm`.

All three models passed the four varied ONNX Runtime decoded-text cases
(**12/12**: `16x16`, English, low contrast, and `3000x80`) with the new
default. The N=4 public batch smoke stayed serial-result-identical and
measured **1.314x**, **1.210x**, and **1.087x** speedup for tiny, small, and
medium. The low-level exact/approximate SIMD smoke and the Radeon 780M Vulkan
admission smoke also passed. A current short hybrid sample was **35.627 /
84.529 / 294.957 ms** (tiny/small/medium), so the transfer-inclusive admission
rule continues to select Vulkan only for segments that actually meet the
no-slower condition; this does not claim complete GPU-only PP-OCRv6 support.

### 2026-08-13: terminal-projection SIMD coverage expansion

The dependency-free kernel smoke now includes the exact terminal projection
geometries of every shipped recognizer: `4x80x6906` for tiny and
`4x120x18710` / `4x192x18710` for small/medium, plus the bounded terminal-CTC
route. This explicitly exercises wide vocabulary tails, bias initialization,
the AVX-512 four-row GEMM reuse tile, and the unchanged scalar/AVX2/NEON
fallback contract rather than inferring coverage from a smaller synthetic
matrix.

A renewed CPU A/B on the English page (three warm-ups, 12 runs, 16 workers,
exact terminal logits) measured tiny/small/medium at **28.508 / 62.702 /
192.242 ms** with the default reconstruction tile, versus **28.950 / 63.142 /
198.772 ms** with `PPOCR_DISABLE_AVX512_CONV2X2_TILE4=1` (**1.5% / 0.7% /
3.3% lower**). Separately disabling the already-default AVX-512 four-row
GEMM tile produced **30.019 / 63.584 / 196.993 ms**, confirming that its main
measured benefit is medium's wide transformer projections. These remain
shared-host snapshots, not cross-machine guarantees.

### 2026-08-13: batched AVX-512 2x2 reconstruction tile

`Conv2dBatch` now uses the same AVX-512 four-output `2x2` valid-convolution
tile as the single-image dispatcher. Its scheduler owns one
`[batch, output-channel-tile]` task instead of one output plane, preserving
the exact per-channel reduction order while reusing every loaded input vector
over four filters for detector batches. The existing AVX2, NEON, scalar, tail,
and `PPOCR_DISABLE_AVX512_CONV2X2_TILE4=1` fallback paths remain intact.

With four equal English pages, `det_batch_size=4`, `rec_batch_size=4`,
four-way preprocessing, two warm-ups, and five timed runs, serial-vs-batch
results remained bit-identical. The tile-enabled batch means were **91.918 /
213.696 / 781.774 ms** for tiny/small/medium, versus **93.346 / 223.177 /
939.356 ms** with the tile disabled: **1.5% / 4.2% / 16.8% lower** batch
latency on this shared AVX-512 host. The corresponding complete
serial-to-batch speedups were **1.290x / 1.194x / 1.096x**. All three models
also passed their four-image ONNX Runtime decoded-text checks (**12/12**).

### 2026-08-13: refreshed small-to-large memory ladder

The native memory regression now exercises one live medium PP-OCRv6 instance
over a deterministic ascending image sequence: `16x16 -> 64x64 -> 160x120 ->
320x240 -> 640x480 -> 1280x720 -> 1920x1080 -> 2560x1440 -> 64x64`.  Each
image is decoded, inferred, destroyed, and only then sampled.  The report
therefore records process private bytes and Windows working-set bytes for
every resolution, plus whether the final small image returns below the
pre-large high-water mark and whether it immediately declines from the
preceding largest-image sample.

A fresh CPU run with 16 workers and `PPOCR_APPROX_GELU=1` passed two cycles
from a **143,192,064-byte** warmed private baseline.  The final `64x64`
samples were **148,197,376 bytes** (+3.50%) and **147,365,888 bytes**
(+2.91%); both were below the respective pre-return peaks of **149,053,440**
and **150,142,976 bytes**, and comfortably passed the 20% bounded-recovery
gate.  In this particular shared-Windows-host measurement, neither final
sample immediately fell below its directly preceding `2560x1440` sample
(+1.67% / +1.76%), and working set showed the same allocator-capacity
retention.  This is reported as `declined_after_largest=false`, not presented
as an immediate decommit: the completed large image and its inference
temporaries have already been destroyed before measurement.  The durable
per-resolution report is
`build/memory_ladder_medium_cpu_tile4_20260813.json`.

### 2026-08-13: tiny resolution-ladder recovery rerun

The same native small-to-large-to-small memory gate was also run against the
tiny PP-OCRv6 model with 16 CPU workers and `PPOCR_APPROX_GELU=1`.  It uses
the deterministic sequence `16x16 -> 64x64 -> 160x120 -> 320x240 ->
640x480 -> 1280x720 -> 1920x1080 -> 2560x1440 -> 64x64`, sampling only after
each decoded image and its inference temporaries have gone out of scope.

Both cycles passed the 20% bounded-recovery gate from a **9,195,520-byte**
warmed private-byte baseline.  Immediately after `2560x1440`, the final
`64x64` sample fell from **9,940,992** to **9,232,384 bytes** (**-7.13%**) in
cycle one, and from **10,711,040** to **9,330,688 bytes** (**-12.89%**) in
cycle two.  Working set declined in both cycles as well.  This directly
confirms recovery after the largest image on the current host; the durable
per-resolution report is `build/memory_ladder_tiny_cpu_latest.json`.

### 2026-08-13: Vulkan terminal-GELU chain and immutable-chain cache

The Vulkan MobileNet `depthwise -> pointwise` chain now has an optional mode
that applies the existing opt-in AVX2/AVX-512 GELU approximation in its final
GPU writeback.  It avoids the former GPU readback followed by a full CPU GELU
pass for the medium-only graph fusion.  This path is selected only when
`PPOCR_APPROX_GELU=1` and the CPU dispatcher would make that same approximate
choice for the same logical tensor size; exact ONNX Erf-GELU, ARM/NEON, and
small tensors keep their established CPU behavior.  The chain also reuses its
immutable depthwise weights, bias, and packed pointwise parameters across
consecutive submissions, while invalidating that cache whenever a shared
Vulkan scratch binding is overwritten.

The AMD Radeon 780M Vulkan smoke validates both regular and GELU-fused chain
outputs against the shared CPU kernels.  Hybrid admission still measures the
complete upload, dispatch, fence, and readback boundary and only chooses GPU
when it is no slower; on this host the representative depthwise-pointwise
chain remained CPU-preferred (**0.601 ms GPU / 0.183 ms CPU**), while
affine+Swish and depthwise+Swish primitives were admitted in the same smoke.
This is intentional: the change makes a qualifying GPU segment cheaper
without relaxing the no-slower policy.

With 16 workers and `PPOCR_APPROX_GELU=1`, decoded-text parity versus ONNX
Runtime passed all four diverse inputs for each official model (**12/12**):
`16x16`, English, low contrast, and `3000x80` ultra-wide text.  The paired
eight-run `en.ppm` CPU/hybrid snapshots were tiny **32.042 / 34.855 ms**,
small **63.781 / 70.924 ms**, and medium **191.886 / 219.099 ms**.  Thus this
UMA run correctly retains CPU for the complete models; it is not presented as
a blanket GPU speed claim.  Reports are
`build/accuracy_{tiny,small,medium}_vulkan_gelu_fusion_20260813.json` and
`build/bench_{tiny,small,medium}_cpu_hybrid_gelu_fusion_20260813.json`.

The two-cycle medium `16x16 -> ... -> 2560x1440 -> 64x64` CPU memory ladder
also passed from a **147,148,800-byte** warm baseline.  Private bytes fell
immediately after the largest image in both cycles (**-2.01%** and **-1.39%**)
and working set fell as well; the durable report is
`build/memory_ladder_medium_cpu_vulkan_gelu_fusion_20260813.json`.

### 2026-08-13: refreshed ascending-resolution memory measurement

A fresh two-cycle medium CPU run (16 kernel workers,
`PPOCR_APPROX_GELU=1`) reconfirmed the deterministic
`16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 -> 1280x720 -> 1920x1080
-> 2560x1440 -> 64x64` sequence.  The checker samples process private bytes
and Windows working set only after each source image and its inference result
have left scope.  It passed the 20% bounded-recovery gate from a
**143,245,312-byte** warmed private baseline.

In cycle 1 the final `64x64` sample was **146,501,632 bytes** (+2.27% from
baseline, -0.63% from the pre-return private-byte peak); in cycle 2 it was
**143,319,040 bytes** (+0.05%, -4.66%).  The returned small image was below
the pre-return private-byte and working-set peaks in both cycles.  It was
**1.89%** above the immediately preceding `2560x1440` private-byte sample in
cycle 1, but **2.04%** below it in cycle 2; the working set follows the same
pattern.  Therefore the report truthfully records
`declined_after_largest=false` for cycle 1 and `true` for cycle 2 instead of
claiming unconditional immediate decommit.  This distinguishes bounded
live-memory recovery from Windows allocator capacity retention.  Full
per-resolution evidence is in
`build/memory_ladder_medium_cpu_latest_20260813.json`.

### 2026-08-13: SE-gate fusion investigation

The detector's largest squeeze-excitation block (`ReduceMean -> 1x1 -> ReLU
-> 1x1 -> HardSigmoid -> channel Mul`) was profiled as a large-page memory and
traffic candidate.  A strict graph fusion was added behind
`PPOCR_ENABLE_SE_GATE_FUSION=1`: it retains the dying NCHW source allocation,
forms only compact `[N,C,1,1]` gate storage, then scales the source in place.
It preserves the original per-channel FP32 reduction and gate order, and the
tiny/small/medium text regression passed **12/12** cases with it enabled.

It is intentionally **not** a production default yet.  On the current
16-worker AVX-512 host, the 30-run `en.ppm` A/B was favourable for tiny
(**30.926 -> 29.772 ms**, 1.039x), but regressed small (**61.034 -> 63.710
ms**) and was neutral for medium (**205.271 -> 205.028 ms**).  A three-run
medium `2560x1440` page A/B was also within noise but not a reliable win
(**2924.075 -> 2952.852 ms**).  Retaining this as opt-in prevents a
memory-oriented fusion from silently violating the all-three-model latency
requirement; the exact gate pattern remains available for a future
device-resident Vulkan chain.

After this investigation, a fresh medium two-cycle resolution ladder again
passed the 20% bounded-recovery gate.  Its warmed private-byte baseline was
**143,261,696 bytes**.  The final `64x64` sample fell below the immediately
preceding `2560x1440` sample in cycle 1 (**-1.70%**) and remained within the
gate in cycle 2 (**+2.13%**); working-set results and every resolution are in
`build/memory_ladder_medium_cpu_post_se_experiment_20260813.json`.

### 2026-08-13: AVX-512 stride-two NCHW batch tile

The AVX-512 `3x3, stride=2` NCHW batch scheduler now assigns one task to a
four-output-channel tile instead of invoking the kernel one channel at a
time.  Its SIMD body therefore shares every gathered/packed source vector
across four filters, exactly as the single-image dispatcher already did.
Output-channel ownership remains disjoint and each output retains the same
ascending FP32 accumulation order.  The optimization is dynamically entered
only after the existing AVX-512 runtime feature check; AVX2, scalar, and ARM
NEON paths are unchanged.  Set
`PPOCR_DISABLE_AVX512_STRIDE2_BATCH_TILE4=1` for a deployment A/B fallback.

The low-level kernel smoke and Vulkan smoke passed.  Decoded-text comparison
against ONNX Runtime passed all four varied inputs (`16x16`, English,
low-contrast, `3000x80`) for tiny, small, and medium (**12/12**); reports are
`build/accuracy_{tiny,small,medium}_stride2_batch_tile4_20260813.json`.

On four equal English pages, real detector and recognizer NCHW batches
(`det_batch=4`, `rec_batch=4`, exact width, two warm-ups, twelve timed runs)
remained serial-result-identical and measured these complete
serial-to-batch speedups on the 16-worker AVX-512 host: **1.573x** tiny
(184.036 / 116.981 ms), **1.379x** small (407.445 / 295.523 ms), and
**1.279x** medium (1105.502 / 864.359 ms).  This exercises the new stride-two
batch route directly, rather than inferring a batch benefit from a single
page.  Exact sample records are
`build/batch_{tiny,small,medium}_stride2_batch_tile4_20260813.txt`.

The same refreshed eight-run single-English CPU/Hybrid check measured
CPU **33.938 / 71.164 / 206.282 ms** and Hybrid
**36.744 / 74.706 / 292.331 ms** for tiny/small/medium.  On this UMA Radeon
780M host, Hybrid remains slower end-to-end, while individual admitted
Vulkan affine+Swish and depthwise+Swish segments still obey the
transfer-inclusive no-slower policy.  The result is not presented as a
whole-model GPU speed claim.

### 2026-08-13: heterogeneous-size batch regression

`bench/heterogeneous_batch_regression.py` adds a repeatable multi-size page
batch gate around `ppocr_batch_smoke`.  Its PPM corpus deliberately combines
`16x16`, ordinary two-line text, low-contrast text, `3000x80` wide text,
`80x3000` portrait text, a dense `1920x1080` UI page, and a `2560x1440`
screenshot.  It executes both exact-width (`PPOCR_REC_WIDTH_BUCKET=1`) and
a candidate padded-width grouping, while `ppocr_batch_smoke` verifies every
batch result is identical to serial inference.  The JSON records both timing
samples rather than promoting a padding policy from a narrow equal-page test.

On the current 16-worker AVX-512 CPU with approximate GELU, all three models
passed serial-identity on this seven-image / 186--188-result corpus.  The
exact-width batch means were **473.748 ms** (tiny), **1771.887 ms** (small),
and **8437.291 ms** (medium), with serial-to-batch speedups of **1.258x**,
**1.156x**, and **1.038x**, respectively.  A 16-pixel candidate bucket
measured **487.901 ms** (+3.0%), **1796.819 ms** (+1.4%), and **8945.280 ms**
(+6.0%).  Exact-width therefore remains the lower-memory CPU default; the
candidate remains an exposed deployment knob for workloads where reduced
shape fragmentation pays back its bounded right-padding.  Reports are in
`build/heterogeneous_batch_{tiny,small,medium}_bucket16_20260813.json`.

### 2026-08-13: batch-invariant GELU policy

The selective GELU dispatch now receives the logical per-sample element count
from every generic and fused graph route.  Consequently, packing four equal
pages/crops into an NCHW batch cannot change a short tensor from exact Erf to
the opt-in approximate formula merely because the batch has four times as many
elements.  This closes a batch-correctness edge case while keeping the medium
large-map AVX-512/AVX2 acceleration.  The low-level GELU smoke passed in both
exact and approximate configurations, and all three models again passed the
four-image ONNX Runtime decoded-text gate (**12/12**).

An N=4 CPU public-batch smoke with `det_batch_size=4`, `rec_batch_size=4` and
four-way preprocessing remained serial-result-identical for every model. On
this shared AVX-512 host it measured tiny **1.346x**, small **1.090x**, and
medium **1.055x** serial-to-batch speedup.  A new paired medium CPU A/B (two
warm-ups, eight runs) measured **211.217 ms** with the corrected SIMD route
and **219.778 ms** with `PPOCR_DISABLE_APPROX_GELU_SIMD=1` (**3.9%** lower
mean latency). Hybrid measured **314.123 ms** in the same short sample; the
strict transfer-inclusive Vulkan admission therefore remains necessary and
continues to retain CPU for transfer-bound operators.

### 2026-08-13: Vulkan batch-admission parity correction

The per-shape Vulkan admission probes for pointwise Conv and residual
pointwise Conv now benchmark the same batched CPU SIMD kernels used by live
`[N,C,H,W]` OCR execution.  Previously these two probes used a serial loop of
single-image kernels even though the executor flattens batch/channel tiles;
that could make a GPU segment appear no slower than a weaker CPU reference.
The correction does not change model arithmetic or force a GPU path. It makes
the hybrid policy stricter and accurate: Vulkan is selected only when its full
upload, dispatch, synchronization, readback, and validation boundary is no
slower than the real batched CPU alternative.

`ppocr_vulkan_smoke` and the full SIMD kernel smoke passed on the local AMD
Radeon 780M / AVX-512 host.  The current primitive measurements correctly
retain CPU for pointwise Conv (`0.22340 ms` GPU versus `0.02218 ms` CPU) and
residual pointwise Conv+ReLU (`0.24984 ms` versus `0.03832 ms`), while keeping
GPU for the validated depthwise+Swish sample (`0.41966 ms` versus `0.42462
ms`).  This is explicit evidence of the requested no-slower hybrid policy,
not a claim of universal GPU speedup or GPU-only availability.

### 2026-08-13: current three-model CPU/hybrid snapshot

With `PPOCR_BENCH_THREADS=16` and `PPOCR_APPROX_GELU=1`, a refreshed CPU
measurement on the two-line English PPM used two warm-ups and twelve timed
runs.  Tiny measured **33.025 ms** (30.280 FPS), small **70.530 ms** (14.178
FPS), and medium **246.420 ms** (4.058 FPS).  A controlled medium worker scan
on the same shared host measured 8 / 12 / 16 workers at **366.673 / 282.361 /
246.420 ms**, respectively; this validates the current 16-worker ceiling for
the broad medium graph without claiming that all deployments share that curve.

Hybrid mode with the same model/input and two warm-ups/eight runs measured
tiny **37.400 ms**, small **75.953 ms**, and medium **235.987 ms**.  Medium
therefore saw a **4.2%** lower mean latency on this local hybrid run, while
tiny/small correctly remain CPU-preferred at the segment level when transfers
do not pay back.  A paired medium ONNX Runtime 1.28 CPUExecutionProvider run
(matching 16-thread budget, two warm-ups/eight runs) measured **399.188 ms**;
the native medium CPU snapshot is **38.3%** lower latency and hybrid is
**40.9%** lower on this host.  These are shared-host measurements rather than
portable guarantees; model accuracy and the hybrid admission rule remain
independent of benchmark mode.

`bench/stress_regression.py` now resolves a default `.png` case to a sibling
`.ppm` case when necessary. The checked-in native regression corpus can
therefore run directly without duplicating the large source images or adding
an image decoder to the C++ executable. The tiny-model CPU stress gate passed
all **11/11** cases: dense UI, blank, single word, ultra-wide/tall strips,
tiny, low-contrast, rotated, dense blobs, and two screenshot sizes.

### 2026-08-13: Vulkan GELU-chain smoke repair and refreshed checks

The Vulkan smoke's depthwise-to-pointwise mode 30 test now calculates the
same explicit Pad鑼?tanh GELU approximation as the shader. Previously the test
accidentally compared this opt-in approximation with exact `kernels::Gelu()`
when `PPOCR_APPROX_GELU` was unset, producing a false failure even though the
shader's mode was correct. This is a test-only correction: it does not change
the default exact-GELU execution policy or GPU admission rule. The rebuilt
AVX-512 kernel smoke and Radeon 780M Vulkan primitive suite passed, including
the device-resident depthwise閳姫ointwise閳墱ELU chain.

The refreshed CPU-versus-ORT `en.ppm` comparison (16 kernel workers, opt-in
approximate GELU, 2 warm-ups/20 timed runs) measured native tiny **40.480 ms**
versus ORT **122.008 ms** (**66.8% lower latency**), small **79.199 ms** versus
**183.173 ms** (**56.8% lower**), and medium **242.245 ms** versus **291.551
ms** (**16.9% lower**).  These are local shared-host measurements, not a
portable guarantee. Decoded-text parity against ORT also passed four diverse
inputs for each model (English, mixed text, single-line text, and low-contrast
multi-line text): **12/12**.

Hybrid retains the strict full-boundary admission rule and therefore only
uses a Vulkan segment when its measured H2D閳妿ispatch閳姁ence閳墬2H result is no
slower than the matching CPU SIMD work. A seven-image varied-size hybrid batch
(16x16, English, low contrast, ultra-wide, ultra-tall, 1920x1080 UI, and
2560x1440 screenshot) stayed serial-result-identical and took **850.547 ms**
batched versus **1049.532 ms** serial (**1.234x**) with four graph workers.
A two-cycle tiny Hybrid resolution ladder also passed every bounded memory
recovery limit; its final `64x64` samples stayed below the warmed
119,021,568-byte private baseline. `gpu_only` remains deliberately rejected:
the complete OCR graph and DB post-processing are not yet device-resident, so
silently using a partial GPU path would violate the public backend contract.

### 2026-08-13: refreshed ascending-resolution memory recovery check

The repository includes a reproducible ascending-resolution PPM ladder and a
native process-memory checker: `bench/generate_memory_ladder.py` creates
`16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 -> 1280x720 -> 1920x1080
-> 2560x1440 -> 64x64`; `ppocr_mem_soak` loads, infers, and destroys each
image before sampling Windows private bytes and working set.  The final
`64x64` sample is therefore a direct observation after the largest image,
rather than a retained source-image allocation.  The checker requires the
returned small-image private bytes to stay within 20% of the warmed baseline,
the preceding `1920x1080` sample, and the immediately preceding largest-page
sample; it additionally records whether private bytes and working set actually
declined after `2560x1440`.

A fresh two-cycle CPU run with `PPOCR_BENCH_THREADS=16` and
`PPOCR_APPROX_GELU=1` passed for both available dictionary/model pairs. Tiny
returned from **10,756,096 B** at `2560x1440` to **10,199,040 B** (-5.18%) in
cycle 1 and from **9,953,280 B** to **9,420,800 B** (-5.35%) in cycle 2;
private memory therefore declined directly after the large page in both
cycles. Medium returned from **146,243,584 B** to **143,228,928 B** (-2.06%)
in cycle 1; cycle 2's returned sample was **146,063,360 B**, 1.58% above that
cycle's immediate `2560x1440` sample but still below its pre-return peak and
0.62% below the warmed baseline. Both models met every bounded-recovery gate.
The complete per-resolution private-byte and working-set records are retained
in `build/memory_ladder_tiny_cpu_resolution_recheck_20260813.json` and
`build/memory_ladder_medium_cpu_resolution_recheck_20260813.json`. These are
host-specific allocator observations, not a guarantee that every platform will
immediately decommit heap capacity after a large image.

### 2026-08-13: SE workspace reuse and refreshed medium memory ladder

`SqueezeExcitationGateInplace` now stores one `[N,C]` gate/mean buffer and a
single reusable `[reduced-C]` hidden row.  The former implementation retained
two `[N,C]` temporary buffers plus `[N,reduced-C]`; the helper's temporary
workspace is consequently reduced from `2*N*C + N*reduced-C` to
`N*C + reduced-C` floats, without changing its FP32 accumulation order or
the completed gate values.  This is a local SE-workspace reduction, not a
claim that total process memory drops by the same amount.

The rebuilt SIMD and Vulkan smoke suites passed, and decoded-text parity with
ONNX Runtime remained **4/4 for each of tiny, small, and medium** across
English, mixed, single-line, and low-contrast inputs.  The refreshed tiny and
small reports are
`build/accuracy_{tiny,small}_cpu_se_workspace_20260813.json`; medium was split
into `build/accuracy_medium_cpu_se_workspace_20260813_part{1,2}.json` to keep
each check bounded.  A fresh two-cycle CPU ascending-resolution run
(`16x16 -> ... -> 2560x1440 -> 64x64`, 16 workers, approximate GELU) also
passed every 20% bounded-recovery gate.  Its warmed private baseline was
**147,709,952 B**; the final small image was **143,351,808 B** and
**143,364,096 B**, respectively.  Private bytes and working set both declined
directly after `2560x1440` in both cycles.  Per-resolution private and working
set samples are retained in
`build/memory_ladder_medium_cpu_se_workspace_20260813.json`.

### 2026-08-13: extended-resolution and aspect-ratio memory check

The reproducible ladder now also covers `3000x1600`, `3840x2160`, the
ultra-wide `4096x256`, and ultra-tall `256x4096` before returning to `64x64`.
This exercises both pixel-count growth and detector resize branches that a
landscape-only corpus misses.  On the local 16-worker CPU, both tiny and
medium passed two cycles of this extended sequence.  For medium the
143,294,464-byte warmed baseline returned to **143,347,712 B** (+0.04%) and
**143,392,768 B** (+0.07%); both samples were below the immediately preceding
`3840x2160` page and their cycle high-water marks, and working set declined as
well.  Tiny returned to **10,211,328 B** (+1.47%) and **9,596,928 B** (-4.64%)
from its 10,063,872-byte baseline; its private bytes declined after the 4K
page in both cycles.  Its first-cycle working set did not immediately decline
from the preceding 4K sample, but remained below the cycle high-water mark;
the second cycle did decline.  Full durable resolution-by-resolution reports are
`build/memory_ladder_{tiny,medium}_cpu_extended_aspect_20260813.json`.

### 2026-08-13: staged post-4K memory recovery check

The memory ladder now continues after `3840x2160` with `1920x1080`,
`4096x256`, and `256x4096` before its final `64x64` sample. This distinguishes
recovery after a large area from recovery after the detector's two extreme
aspect-ratio resize paths. A fresh medium CPU pass (16 workers, approximate
GELU) warmed at **144,003,072 B** private bytes, peaked at
**149,565,440 B**, and returned to **144,084,992 B** after the full tail
(+0.06% over the warm baseline; -3.31% versus the 4K sample). Its working set
also returned from the 4K **152,662,016 B** to **147,812,352 B**. The durable
per-resolution report is
`build/memory_ladder_medium_cpu_staged_recovery_20260813.json`. These are
local allocator observations, not a cross-platform decommit guarantee.

### 2026-08-13: selective default SE graph fusion

SE gate fusion is now enabled by default only for detector blocks with at
least 512 input channels, which selects the three high-cost medium blocks and
keeps tiny/small on their lower-overhead established paths.  The full-shape
experiment remains available through `PPOCR_ENABLE_SE_GATE_FUSION=1`; disable
all default fusion with `PPOCR_DISABLE_SE_GATE_FUSION=1`, or tune the boundary
with `PPOCR_SE_GATE_FUSION_MIN_CHANNELS`.  This is a genuine graph/operator
fusion: it replaces `ReduceMean -> Conv -> Relu -> Conv -> HardSigmoid -> Mul`
with one in-place gate operation, avoiding the broadcast-map destination and
the intermediate graph dispatches.

On the same shared 16-worker AVX-512 host, a 2-warm-up/20-run English-page
CPU snapshot measured **30.982 ms** (tiny), **64.365 ms** (small), and
**195.898 ms** (medium), respectively.  The medium run before this selective
default measured 210.198 ms in a separate 12-run sample; this comparison is
directional because the host is shared, rather than a portable performance
claim.  The existing 20-run CPU-versus-ORT measurements remain the published
cross-engine evidence.  Kernel and Vulkan smoke both passed, and medium
retained ONNX Runtime decoded-text parity on all four diverse images; reports
are `build/bench_{tiny,small,medium}_cpu_selective_sefusion_20260813.json`
and `build/accuracy_medium_cpu_selective_sefusion_20260813_part{1,2}.json`.

### 2026-08-13: folded Conv channel-bias execution path

The graph loader already recognizes the recognizer pattern `Conv ->
Add([1,C,1,1]) -> Identity` and precomputes the resulting per-output-channel
bias. Its executor now passes that folded bias directly to the convolution,
removing the accidental second `AddChannelBias` traversal that had remained
after load-time folding. This keeps the original FP32 order閳ユ攦onvolutional
reduction followed by the same accumulator bias閳ユ攣nd avoids a full NCHW
read/write for each matched node. Set `PPOCR_DISABLE_FOLDED_CHANNEL_BIAS=1`
for a runtime A/B comparison.

All three model sizes retained decoded-text parity with ONNX Runtime on the
four-image English/mixed/single-line/low-contrast corpus (12/12 cases):
`build/accuracy_{tiny,small,medium}_cpu_folded_channel_bias_20260813.json`.
Kernel and Vulkan smoke both passed. On this shared 16-worker AVX-512 host,
a 2-warm-up/16-run CPU snapshot measured **31.574 ms** (tiny), **67.060 ms**
(small), and **201.835 ms** (medium); the matching files are
`build/bench_{tiny,small,medium}_cpu_folded_channel_bias_20260813.json`.
Separate 40-run A/B samples showed a medium reduction from **211.568 ms** to
**201.835 ms** (4.6%), while tiny/small were within normal shared-host noise;
this is therefore retained as a medium-oriented optimization rather than a
claim of uniform speedup on every model or system.

The staged medium CPU memory test also passed after the change:
**143,548,416 B** warmed private bytes, **151,822,336 B** at 4K, and
**143,601,664 B** at the final `64x64` image (+0.04% versus warm; -5.41%
versus 4K). Working set fell from **153,632,768 B** at 4K to
**147,640,320 B**. The durable report is
`build/memory_ladder_medium_cpu_folded_channel_bias_20260813.json`.

### 2026-08-13: refreshed full-resolution memory recovery measurement

The reproducible native memory ladder was rerun after rebuilding the current
CPU/Vulkan sources.  It processes one decoded RGB image at a time in this
order: `16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 -> 1280x720 ->
4096x256 -> 256x4096 -> 1920x1080 -> 2560x1440 -> 3000x1600 -> 3840x2160 ->
1920x1080 -> 4096x256 -> 256x4096 -> 64x64`.  Thus the last small image is
sampled only after the largest-area page and both detector extreme-aspect-ratio
paths have completed and their input images have been destroyed.

With medium PP-OCRv6, CPU backend, 16 kernel workers, and approximate GELU,
the warmed private baseline was **144,879,616 B**.  The `3840x2160` sample was
**151,138,304 B** and the pre-return high-water mark was **152,875,008 B**;
the final `64x64` sample fell to **143,867,904 B** (-0.70% from warm, -4.81%
from the 4K sample, and -5.89% from the cycle high-water mark).  Its Windows
working set likewise fell from **153,780,224 B** at 4K (cycle peak
**156,557,312 B**) to **147,533,824 B** at the final small image.  The
bounded-recovery gate passed and both explicit decline flags are true.  This
is process-level evidence for this host and build, not a promise that every
allocator or Vulkan driver will immediately decommit reusable pages.  The
per-resolution report is
`build/memory_ladder_medium_cpu_post_vulkan_tile_rebuild_20260813.json`.

### 2026-08-13: current small-to-large-to-small memory regression

The current CPU build was also measured with a fresh, reproducible resolution
ladder: `16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 -> 1280x720 ->
4096x256 -> 256x4096 -> 1920x1080 -> 2560x1440 -> 3000x1600 -> 3840x2160`,
followed by `1920x1080 -> 4096x256 -> 256x4096 -> 64x64`.  Each sample loads,
recognizes, and destroys its input image before Windows private bytes and
working set are sampled.

On medium PP-OCRv6 with CPU backend, 16 kernel workers, and approximate GELU,
the warmed private baseline was **143,552,512 B**.  Private bytes reached
**149,356,544 B** at `3840x2160` and fell to **148,066,304 B** at the final
`64x64` sample: **-0.86%** from the 4K sample and **+3.14%** from warm.  The
working set likewise fell from **153,243,648 B** to **151,785,472 B**.  The
bounded-recovery gate passed; both private-byte and working-set decline flags
are true.  This verifies a post-large-image decrease on this host, while the
small residual capacity is expected allocator reuse rather than a leak claim.
The full per-resolution JSON record is
`build/memory_ladder_medium_cpu_resolution_ladder_current_20260813.json`.

### 2026-08-13: dense-page scheduler and model-aware stress recheck

The default CPU crop-graph concurrency is now **8** rather than 12.  This
matches the default SIMD kernel worker budget, avoids cache/bandwidth
contention between outer crop batches and inner AVX-512/AVX2 kernels, and
keeps the public `PPOCR_REC_PARALLELISM` override for host-specific tuning.
On the local AVX-512 CPU (16 configured kernel workers, approximate GELU),
the normal English page measured **33.548 / 70.323 / 210.214 ms** for
tiny/small/medium (2 warm-ups, 8 runs).  Medium was **6.6%** lower than the
comparable 12-way outer-crop configuration (225.056 ms); this is a local
configuration measurement, not a portable performance guarantee.

All three model sizes preserved decoded-text parity against ONNX Runtime over
four varied inputs each (**12/12**): English, mixed text, a single-line crop,
and low-contrast text.  The reports are
`build/accuracy_{tiny,small,medium}_cpu_default8_20260813.json`.
`bench/stress_regression.py` now accepts `--model tiny|small|medium` and has
explicit medium-only box-count bounds for the synthetic blank and dense-blob
cases. This preserves the original tiny/small limits while avoiding a false
failure when the larger detector stably reports its extra valid components.
The 11-image medium stress corpus passed **11/11** with `--model medium`;
the record is `build/stress_medium_cpu_default8_model_bounds_20260813.json`.

### 2026-08-13: dense-page activation bound and refreshed memory check

The default recognizer NCHW batch is now **1** crop (the public
`PPOCR_REC_BATCH_SIZE` override still enables larger batches for measured
multi-page workloads).  A current dense `1920x1080` UI sweep showed that
larger concurrent crop tensors increase medium-model activation pressure and
lose latency on this host.  With CPU, 16 SIMD workers, approximate GELU, and
the eight-way outer scheduler, the default measured **255.141 ms** (tiny,
2 warm-ups/6 runs), **939.888 ms** (small, 2/4), and **3884.903 ms** (medium,
2/4).  Against the matching CPU ONNX Runtime pipeline on the same dense page,
a separate 2-warm-up/4-run sample was **46.0%**, **18.7%**, and **5.9%** lower
latency for tiny/small/medium respectively.  The latter remains a
machine-specific comparison; the dense image and detected-box mix are part of
the benchmark input.  Reports: `build/dense_cpu_batch1_vs_ort_20260813.json`
and `build/dense_batch_size_sweep_cpu_20260813.json`.

The change retained three-model decoded-text parity on four varied inputs
(**12/12**; `build/accuracy_{tiny,small,medium}_cpu_default_batch1_20260813.json`).
A fresh medium CPU resolution ladder also passed.  It warmed at
**143,974,400 B**, reached **148,078,592 B** at `3840x2160`, and returned to
**144,060,416 B** at the final `64x64` image: **-2.71%** versus the 4K sample
and **+0.06%** versus warm.  Windows working set declined from
**151,060,480 B** to **147,656,704 B**; both recovery flags are true.  The
durable per-resolution record is
`build/memory_ladder_medium_cpu_default_batch1_20260813.json`.

### 2026-08-13: recognizer executor allocation reuse

`RunCtcTop1`, the production recognizer route, now reuses a per-worker
thread-local small input-pointer list for its fused and generic node dispatch.
This removes recurring short-lived `std::vector<const Tensor*>` allocations
for every recognizer node and crop while retaining the existing tensor
lifetime plan, exact operator calls, and safe automatic growth for a future
larger input arity. It is deliberately a low-risk allocation/allocator
pressure reduction rather than a claim of an isolated compute-kernel speedup.

After the change, decoded text still matched ONNX Runtime on the four varied
images for tiny, small, and medium (**12/12**), and kernel/Vulkan smoke passed.
A new medium CPU resolution ladder also passed with the full ascending and
recovery sequence. Its private bytes fell from **150,818,816 B** at
`3840x2160` to **143,855,616 B** at the final `64x64` (**-4.62%**); working
set fell from **154,529,792 B** to **147,832,832 B**. The final sample was
2.60% below the warmed baseline and all bounded-recovery/decline checks were
true. See `build/memory_ladder_medium_cpu_executor_scratch_20260813.json`.

The immediate dense-page sanity sample (CPU, 16 kernel workers, approximate
GELU, default recognizer batch) was **255.959 ms / 860.055 ms / 3859.129 ms**
for tiny/small/medium (one warm-up, three runs). Because shared-host timing
varies materially, it is retained only as a post-change sanity record rather
than compared as a claimed percentage gain. The three JSON records are
`build/executor_scratch_bench_{tiny,small,medium}_cpu_20260813.json`.

Hybrid remains guarded by per-shape full-boundary admission (`H2D / dispatch
/ fence / D2H`); it uses Vulkan only when that complete operation is no
slower than the matching CPU SIMD batch kernel. On the local AMD Radeon 780M
snapshot, Hybrid measured 33.469/68.070/264.781 ms for tiny/small/medium,
respectively, so the end-to-end route is still not a GPU speedup on this UMA
device. `gpu_only` remains unavailable until the complete OCR graph and DB
post-processing can remain device-resident.

### 2026-08-13: compact CTC last-use counters

The recognizer's `RunCtcTop1` no longer clones a string-keyed
`unordered_map` of tensor-use counts for every crop. Model loading now assigns
each dynamic activation one compact counter slot; each worker resets a
thread-local `uint16_t` counter vector and continues to resolve only the
fixed names needed by the existing lifetime planner. This removes repeated
map-node allocation/copying from the multi-crop hot path while preserving the
same final-use, in-place, and immediate-release decisions.

The native kernel/Vulkan smoke suites passed, as did decoded-text parity
against ONNX Runtime for all three model sizes over English, mixed text,
single-line, and low-contrast inputs (**12/12**). A heterogeneous seven-image
tiny Hybrid batch (`16x16`, normal text, low contrast, ultra-wide,
ultra-tall, dense 1080p, and 1440p screenshot) remained serial-identical for
all 188 results. The one-run steady-state observation was **1456.274 ms**
batched versus **1485.160 ms** serial; it is not promoted to a general GPU
latency claim.

The accompanying medium CPU full-resolution ladder passed its 20% bounded
recovery gate. The final small image used **148,414,464 B** private memory
(+0.25% versus its warmed baseline and 0.65% below the cycle peak). This
particular Windows allocator run did not immediately decommit relative to the
`3840x2160` checkpoint, so both direct-decline flags are intentionally
recorded as false rather than presented as a memory-reduction claim. Full
per-resolution evidence is
`build/memory_ladder_medium_cpu_ctc_use_slots_20260813.json`.

The dense timing samples were materially host-noisy (tiny **361.536 ms**,
small **1858.371 ms**, medium **4585.517 ms** means) and therefore serve only
as post-change sanity records, not percentage-improvement evidence:
`build/ctc_use_slots_bench_{tiny,small,medium}_cpu_20260813.json`.

### 2026-08-13: explicit post-4K resolution-memory recovery sample

The native memory regression now distinguishes the **first** image after the
`3840x2160` sample (`1920x1080`) from the final `64x64` check.  Its JSON
includes private-byte and working-set decline flags for that immediate 4K
transition, in addition to the existing bounded final-small-image gates. This
avoids accidentally treating a later aspect-ratio sample as proof of direct
large-image recovery.

On this Windows host, a fresh one-cycle medium CPU run over the deterministic
ascending ladder (`16x16` through `3840x2160`) passed all 20% bounded-recovery
limits. Private usage fell from **148,787,200 B** at `3840x2160` to
**148,303,872 B** after the immediately following `1920x1080` input
(**-0.32%**); working set fell from **152,776,704 B** to **151,871,488 B**.
After the staged wide/tall recovery tail, the final `64x64` sample was
**143,667,200 B** private (**-3.08%** versus the warmed baseline). This is a
host/run-specific observation閳ユ摱indows may retain heap capacity on a later run;
the report preserves both direct-decline booleans and all per-resolution
samples. Reproduce it with `bench/generate_memory_ladder.py` and
`bench/memory_ladder_regression.py`; recorded evidence:
`build/memory_ladder_medium_cpu_immediate_4k_recovery_20260813.json`.

### 2026-08-13: current full-resolution memory-recovery check

The deterministic native memory ladder was run again with the current release
build and medium PP-OCRv6 on the CPU backend.  It processes one image at a
time, releases that image before sampling, and covers the complete sequence:
`16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 -> 1280x720 -> 4096x256 ->
256x4096 -> 1920x1080 -> 2560x1440 -> 3000x1600 -> 3840x2160 -> 1920x1080
-> 4096x256 -> 256x4096 -> 64x64`.

On this Windows host, private bytes were **148,770,816 B** at `3840x2160` and
fell immediately to **147,767,296 B** after the next `1920x1080` image
(**-0.67%**).  The working set also fell from **151,744,512 B** to
**150,671,360 B**.  After the full recovery tail, the final `64x64` sample was
**147,222,528 B** private and **151,085,056 B** working set: below the 4K
sample in both measures.  All bounded-recovery gates passed.  This is a
host-specific allocator observation, not a promise that every OS allocator
will immediately decommit reusable heap capacity.  The complete per-resolution
record is `build/memory_ladder_medium_cpu_current_20260813.json`.

### 2026-08-13: generic SIMD Conv+ReLU correctness and memory recheck

The generic AVX-512/AVX2 spatial-convolution fallback now applies its requested
ReLU after the vector convolution writeback. Dedicated fused 2x2/3x3 paths
already performed that activation, but the generic 5x5/7x7 and asymmetric
SIMD fallback did not. This is a correctness repair, not a claimed latency
win. The rebuilt kernel and Vulkan smoke tests pass, and decoded-text parity
against ONNX Runtime passes **4/4** varied inputs for every PP-OCRv6 tier
(tiny, small, medium): English, mixed text, a short line, and noisy
low-contrast text. Reports are
`build/accuracy_{tiny,small,medium}_relu_fix_20260813.json`.

The medium CPU heterogeneous six-image batch smoke (`16x16`, normal English,
mixed text, wide/tall strips, low contrast) was result-identical and measured
**1653.548 ms serial** versus **1414.858 ms batched** (**1.169x** throughput).
A fresh full-resolution CPU memory ladder also passed: its `3840x2160` private
sample was **149,692,416 B**, the immediately following `1920x1080` sample
was **145,428,480 B** (**-2.85%**), and the final `64x64` sample was
**147,177,472 B** (**-0.35%** versus warm baseline). The complete report is
`build/memory_ladder_medium_cpu_relu_fix_recheck_20260813.json`.

### 2026-08-13: refreshed diverse CPU versus ONNX Runtime measurement

Using the current release build, dynamic AVX-512 dispatch, CPU-only backend,
`PPOCR_BENCH_THREADS=16`, five warm-ups, and 30 timed iterations per case, a
new paired measurement confirms a material end-to-end latency advantage over
ONNX Runtime CPUExecutionProvider for all three official PP-OCRv6 tiers on two
different input shapes.  This is host-specific evidence, not a cross-hardware
guarantee; both engines ran sequentially in the same process environment.

| Input | Model | C++ mean | ORT mean | C++ latency reduction |
|---|---|---:|---:|---:|
| `en.ppm` | tiny | 32.653 ms | 125.618 ms | 74.01% |
| `en.ppm` | small | 68.304 ms | 180.432 ms | 62.14% |
| `en.ppm` | medium | 208.100 ms | 366.127 ms | 43.16% |
| `wide_strip_3000x80.ppm` | tiny | 30.776 ms | 65.817 ms | 53.24% |
| `wide_strip_3000x80.ppm` | small | 60.182 ms | 129.017 ms | 53.35% |
| `wide_strip_3000x80.ppm` | medium | 175.134 ms | 272.745 ms | 35.79% |

The full machine-readable measurement is
`build/bench_cpu_ort_diverse_refresh_20260813.json`. It complements rather
than replaces the larger noisy/dense stress cases: those cases exercise memory
and batch robustness and can be affected more by host scheduling/cache noise.

### 2026-08-13: current CPU-versus-ORT recheck

After the current SIMD/scheduler rebuild, the paired CPU-only comparison was
rerun with dynamic AVX-512 enabled, `PPOCR_BENCH_THREADS=16`, two warm-ups,
and ten timed iterations per case.  The compact English page and a 3000x80
ultra-wide strip cover normal and extreme-aspect detector resize paths.  All
three tiers remain faster than ONNX Runtime CPUExecutionProvider on this host;
the lower reduction on medium's short page reflects host timing variance and
is recorded rather than hidden.

| Input | Model | C++ mean | ORT mean | C++ latency reduction |
|---|---|---:|---:|---:|
| `en.ppm` | tiny | 33.256 ms | 121.671 ms | 72.67% |
| `en.ppm` | small | 81.696 ms | 180.725 ms | 54.80% |
| `en.ppm` | medium | 246.343 ms | 374.196 ms | 34.17% |
| `wide_strip_3000x80.ppm` | tiny | 24.297 ms | 59.489 ms | 59.16% |
| `wide_strip_3000x80.ppm` | small | 53.559 ms | 101.561 ms | 47.26% |
| `wide_strip_3000x80.ppm` | medium | 152.553 ms | 263.361 ms | 42.07% |

The reproducible JSON record is
`build/bench_cpu_ort_diverse_current_20260813.json`.  It is a local-machine
measurement, not a guarantee for every processor or ONNX Runtime build.

### 2026-08-13: blocked recognizer transpose

The recurrent PP-OCRv6 recognizer exchanges both `[N,T,C] <-> [N,C,T]` and
`[N,H,C,T] <-> [N,H,T,C]` layouts.  Their dedicated copy paths now transpose
`32x32` cache tiles instead of continually evicting a full source/destination
matrix row.  The operation is a pure element relocation, so it preserves
values bit-for-bit and applies to scalar, AVX2, AVX-512, and NEON builds.

On this AVX-512 host with `PPOCR_BENCH_THREADS=16`, three independent runs of
12 timed English-page inferences changed mean latency from **32.120 to
30.530 ms** (tiny, **4.95%**), **62.793 to 64.053 ms** (small, **-2.01%**),
and **192.745 to 190.614 ms** (medium, **1.11%**).  The small-model result is
within host scheduling noise and is recorded rather than promoted as a broad
claim; no model-specific switch is required.  Raw paired samples are
`build/bench_transpose_tile_{baseline,tiled}_20260813.json`.  Text parity
against ORT remained 3/3 across English, ultra-wide, and low-contrast inputs
for all tiers in `build/accuracy_transpose_tiled_core_20260813.json`.

The same current medium build passed the full small-to-4K-to-small memory
ladder: `3840x2160` was **149,356,544 B** private / **153,313,280 B** working
set, the immediate following 1080p sample fell to **148,262,912 B** /
**152,317,952 B**, and the final `64x64` sample was **148,324,352 B** /
**152,129,536 B**.  Full per-resolution evidence:
`build/memory_ladder_medium_cpu_transpose_tiled_20260813.json`.

### 2026-08-13: CPU/Hybrid batch recheck and GPU-only boundary

The public three-policy contract was rechecked on the local Radeon 780M:
Vulkan loader and compute are present, while `gpu_only` explicitly rejects
construction because PP-OCRv6 still needs device implementations for its
complete detector, recognizer, preprocessing, and DB/CTC postprocessing
graphs.  It does not silently execute on CPU.  Hybrid remains usable and
continues to select each Vulkan segment only after its complete synchronous
`H2D + dispatch + fence + D2H` path is correct and no slower than CPU.

With four same-shape English pages, `det_batch_size=4`, `rec_batch_size=4`,
one graph worker, and two timed iterations, the verified `RecognizeBatch()`
result-identical speedups over four serial calls were **1.589x / 1.256x /
1.140x** on CPU for tiny/small/medium and **1.598x / 1.323x / 1.225x** in
Hybrid.  This is real cross-page NCHW batching, not padding unrelated page
sizes.  The raw output is `build/bench_batch4_cpu_hybrid_20260813.json`.

### 2026-08-13: AVX-512 recognizer GEMM tile admission

The AVX-512 GEMM implementation retains its two-row and four-row kernels,
but the four-row tile is now opt-in (`PPOCR_ENABLE_AVX512_GEMM4ROW=1`) rather
than the default.  A paired `PPOCR_BENCH_THREADS=16` measurement showed that
the larger register footprint is beneficial only for some medium shapes and
regresses the shipped workload overall.  With the default two-row tile and
three warm-ups/15 runs, current means were **28.885 / 64.840 / 201.871 ms**
on the English page and **20.263 / 48.142 / 134.558 ms** on the 3000x80 strip
for tiny/small/medium. The control data is
`build/bench_gemm4row_{ab_current,off_repeated}_20260813.json` and the final
default record is `build/bench_gemm2row_default_20260813.json`.

Text parity remains **3/3** for each model on English, ultra-wide, and
low-contrast inputs against ONNX Runtime:
`build/accuracy_gemm2row_core_20260813.json`. This change keeps the exact
per-row K-order and applies only after dynamic AVX-512 capability checks;
AVX2, NEON, and scalar dispatch are unchanged.

### 2026-08-13: hot-path ISA configuration caching

The runtime ISA policy remains dynamic (CPUID/XCR0 is still checked before
entering AVX-512), but process-scoped environment switches for pointwise
tiles, 2x2 tiles, wide tiles, and the 2x2 SAME kernel are now cached once.
These predicates occur repeatedly in the detector and recognizer; eliminating
repeated environment lookups reduces dispatcher overhead without changing an
operator's arithmetic or the AVX2/NEON/scalar fallback. On the current
16-worker AVX-512 host, the final English-page smoke measured **30.462 ms**
tiny, **62.268 ms** small, and **190.709 ms** medium. Raw result:
`build/bench_dispatch_cache_current_20260813.json`.

All three tiers retained 3/3 ORT decoded-text parity on English, ultra-wide,
and low-contrast inputs (`build/accuracy_dispatch_cache_core_20260813.json`),
and both CPU kernel and Vulkan primitive smoke tests passed.

### 2026-08-13: detector BatchNorm activation reuse

The generic graph executor now mirrors the production CTC executor for a
final-use plain BatchNorm: it applies the alias-safe affine transform directly
to the dying input activation, then transfers the tensor name to the graph
output. This removes one same-sized detector feature-map allocation/copy at
eligible boundaries without changing the BatchNorm arithmetic or its dynamic
coefficient handling. It is guarded by the existing
`PPOCR_DISABLE_BATCHNORM_INPLACE=1` deployment A/B switch.

All three model tiers retained 3/3 decoded-text parity against ONNX Runtime on
English, ultra-wide, and low-contrast inputs
(`build/accuracy_bn_inplace_core_20260813.json`); CPU and Vulkan smoke also
passed. The refreshed medium full ladder passed with a 4K private/working-set
sample of **148,881,408 B / 152,858,624 B**, immediately declining at the
following 1080p image to **147,857,408 B**, then returning to
**143,728,640 B / 147,775,488 B** on the final 64x64 image. Complete records:
`build/memory_ladder_medium_cpu_bn_inplace_20260813.json` and
`build/bench_bn_inplace_current_20260813.json`.

### 2026-08-13: single-pass SIMD CTC ArgMax

AVX-512 and AVX2 CTC ArgMax no longer scan each vocabulary row twice. The
SIMD reduction now retains each lane's source index as it computes its local
maximum, then performs one scalar lane/tail reduction with the same strict
`>` first-maximum rule as the portable path. This removes a second full read
of each 6,906/18,710-class logits row while preserving the scalar fallback
for malformed NaN logits. The kernel smoke now explicitly covers ties across
SIMD lanes and vector tails.

The current 16-worker English-page smoke was **29.751 ms** tiny,
**60.676 ms** small, and **226.997 ms** medium
(`build/bench_argmax_single_pass_20260813.json`); timing remains host-noisy,
so this record is evidence of correctness rather than a broad end-to-end
speed claim. All three tiers retained 3/3 ORT decoded-text parity on English,
ultra-wide, and low-contrast samples
(`build/accuracy_argmax_single_pass_core_20260813.json`), and the Radeon
780M Vulkan smoke passed.

### 2026-08-13: diverse-shape correctness and terminal-CTC admission recheck

The current CPU implementation was additionally checked against ONNX Runtime
on `en.ppm`, the `3000x80` ultra-wide strip, and `noisy_lowcontrast.ppm` for
all three model tiers.  Decoded line count and text parity passed **3/3** for
tiny, small, and medium; the durable report is
`build/accuracy_diverse_core_20260813.json`.  A short stress smoke on the
low-contrast page and a `80x3000` ultra-tall strip also exercised the
opposite detector resize branch, where it found 3 and 20 text regions,
respectively, for every tier.  The narrow vertical strip does not yet have
text parity with this repository's ORT reference, so it is retained as a
throughput/robustness sample rather than being claimed as a correctness gate.

The bounded terminal-GEMM/CTC path was then A/B measured with three warm-ups
and 15 timed iterations per normal and ultra-wide input.  It improves tiny on
this host (English page **35.105 -> 31.379 ms**) but is neutral/negative for
small and slower for medium's ultra-wide case (**145.585 -> 276.362 ms**).
It therefore remains explicit opt-in via
`PPOCR_ENABLE_FUSED_TERMINAL_CTC=1`; the default executor remains the faster
cross-tier choice.  Raw A/B data: `build/bench_terminal_ctc_ab_20260813.json`.

### 2026-08-13: medium detector AVX-512 tile-pressure recheck

The medium-detector profile identifies regular `3x3` and `5x5`/`7x7`
context convolutions as the main remaining CPU hotspots.  Their eight-output
AVX-512 tiles were rechecked against the established four-output kernels. On
this client AVX-512 host, the larger tiles increase register pressure and can
produce substantial low-contrast tail latency: over eight timed iterations,
the medium `noisy_lowcontrast.ppm` median was **554.202 ms** with the default
four-output tiles versus **571.360 ms** with both eight-output experiments;
the latter's p95 reached **2569.152 ms**. The wide-strip median was likewise
**159.735 ms** (four) versus **163.488 ms** (eight).

Consequently, the proven four-output 3x3/wide-context tiles are now the
default. Eight-output variants remain opt-in for a separately measured server
CPU via `PPOCR_ENABLE_AVX512_CONV3X3_TILE8=1` and
`PPOCR_ENABLE_AVX512_CONV_WIDE8=1`; setting either `PPOCR_DISABLE_*` switch
still disables its matching experiment. Text parity remains 2/2 for tiny,
small, and medium on English and ultra-wide input; reports are
`build/accuracy_{tiny,small,medium}_avx512_tile4default_20260813.json`.

The refreshed medium CPU resolution ladder also passed. Its 4K private sample
was **149,164,032 B**, the immediate following 1080p sample was
**149,123,072 B**, and the final 64x64 sample was **148,738,048 B**. Private
bytes and working set both declined after the 4K image. Full evidence is
`build/memory_ladder_medium_cpu_avx512_tile4default_20260813.json`.

### 2026-08-13: AVX-512 2x2 SAME_UPPER detector-stem kernel

The detector's early `2x2` SAME_UPPER Conv nodes now use a dedicated AVX-512
interior kernel with explicit final-row/final-column zero-padding handling.
This avoids generic variable-kernel address arithmetic on the large feature
maps while retaining runtime AVX2/scalar fallbacks. The low-level smoke suite
checks odd/even dimensions, vector/scalar tails, and fused ReLU. Decoded text
parity against ONNX Runtime passed **2/2** (`en.ppm`, `wide_strip_3000x80`) for
tiny, small, and medium; reports are
`build/accuracy_{tiny,small,medium}_avx512_same2x2_20260813.json`.

On the local AVX-512 host the A/B is strongly workload dependent because the
shared machine has substantial scheduling variance. Repeated medium samples
put the specialized median around **181.580閳?32.008 ms**, versus
**187.559閳?08.236 ms** with the generic path; tiny/small consistently improved
on the short sample. It remains enabled because it removes the generic hot
loop, passes the complete correctness gates, and keeps a one-variable runtime
escape hatch for deployments whose AVX-512 frequency/cache balance differs.

### 2026-08-13: current ascending-resolution memory recovery measurement

`bench/generate_memory_ladder.py` generates deterministic PPM inputs from
`16x16` through `3840x2160`, including wide and tall 1,048,576-pixel strips.
The sequence then processes `1920x1080`, both strips again, and a final
`64x64` image. `ppocr_mem_soak` keeps one OCR instance alive, releases each
decoded image before sampling, and records Windows private bytes and working
set after every inference.

The current medium CPU two-cycle measurement passed all bounded-return gates.
In cycle 1, the `3840x2160` sample was **146,067,456 B** private /
**150,147,072 B** working set; the final `64x64` sample returned to
**143,634,432 B** / **147,345,408 B**, below the 4K sample in both measures.
Cycle 2 similarly returned from **146,886,656 B** / **150,986,752 B** at 4K
to **146,767,872 B** / **150,581,248 B** at the final small image. The first
post-4K 1080p sample declined in both measures in cycle 2; cycle 1 retained a
small amount of reusable allocator capacity before declining by the final
small-image checkpoint. This is a single-host allocator measurement, not an
assertion that an OS must decommit capacity immediately.

Use `--require-post-large-decline` to make immediate private-byte *and*
working-set decline a strict CI gate when that stronger condition is required;
the default remains bounded return because Windows allocator behavior is
non-deterministic. The complete per-resolution record is
`build/memory_ladder_medium_cpu_current_bounded_recovery_20260813.json`.

### 2026-08-13: verified current resolution-memory regression

The reproducible small-to-large-to-small test remains part of the native
regression suite.  It generates and processes, in order,
`16x16 -> 64x64 -> 160x120 -> 320x240 -> 640x480 -> 1280x720 -> 4096x256 ->
256x4096 -> 1920x1080 -> 2560x1440 -> 3000x1600 -> 3840x2160 -> 1920x1080
-> 4096x256 -> 256x4096 -> 64x64`.  Every PPM is decoded, inferred, and
destroyed before collecting Windows private bytes and working set, while one
OCR instance remains alive.  This tests both varied resolution growth and
whether capacity is bounded after a large page.

On the current medium CPU build (16 kernel workers), the fresh two-cycle run
passed all 20% bounded-return gates.  Cycle 1 returned from the 4K sample's
**147,230,720 B** private / **150,204,416 B** working set to
**143,486,976 B** / **147,460,096 B** at final `64x64`.  Cycle 2 showed an
immediate 4K-to-1080p decline in both measures (**148,221,952 B** /
**152,256,512 B** to **147,570,688 B** / **151,240,704 B**); its final small
sample remained below its pre-return peak.  The immediate-decline condition is
reported separately because Windows heap reclamation is allocator-run
dependent; the default regression correctly gates bounded recovery rather than
requiring decommit on every run.  Full per-resolution evidence:
`build/memory_ladder_medium_cpu_current_resolution_recovery_20260813.json`.

### 2026-08-14: exact-size preprocessing fast path

The fused RGB-to-BGR/NCHW preprocessor now recognizes an exact-size resize
region.  In that case bilinear interpolation is an identity, so it writes the
three normalized planes directly, without a horizontal-coordinate table or
four-pixel interpolation work per output value.  It preserves recognizer
right-padding because it writes only the natural-width columns.  The general
bilinear path remains unchanged for every resized image.  For deployment A/B,
set `PPOCR_DISABLE_IDENTITY_RESIZE_FASTPATH=1` before creating an OCR object.

The direct and generic paths produced identical native demo output for tiny,
small, and medium on exact-size `line_en`, `line_zh`, and `single_word`
inputs (`build/identity_resize_cpp_equivalence_20260814.json`).  Each model
also retained ORT decoded-text parity on an exact-size line, normal English
page, and 3000x80 ultra-wide page (3/3 each;
`build/accuracy_identity_resize_cached_{tiny,small,medium}_20260814.json`).
Kernel and Radeon 780M Vulkan smoke passed.

A fresh medium CPU resolution ladder remained bounded after the change: the
4K sample was **148,512,768 B** private / **152,322,048 B** working set and
the final `64x64` sample was **148,197,376 B** / **151,797,760 B**, below the
pre-return peak in both metrics.  Full record:
`build/memory_ladder_medium_cpu_identity_resize_20260814.json`.

The local 16-worker, CPU-only 100-run line benchmark was host-noisy on tiny,
but gave a stable medium improvement: **72.046 ms -> 67.421 ms** mean
(**6.42%** reduction) and **71.770 ms -> 67.466 ms** median.  Small and tiny
are already dominated by model execution on this single-line workload, so
this is recorded as a targeted preprocessing win rather than a claimed
uniform end-to-end speedup.  Raw A/B record:
`build/bench_identity_resize_cached_ab_20260814.json`.

### 2026-08-14: recognizer average-pool compaction

All three PP-OCRv6 recognizers contain the same valid `AveragePool(3x2,
stride=3x2)` bridge between convolutional features and the transformer.  A
dedicated NCHW kernel now executes that exact non-overlapping geometry, and
when its input has a graph-proven final use it compacts the result into the
front of the existing activation allocation before resizing it.  This removes
one bridge-output allocation and releases the unused capacity before the
transformer.  `PPOCR_DISABLE_AVERAGE_POOL3X2_FASTPATH=1` and
`PPOCR_DISABLE_AVERAGE_POOL3X2_INPLACE=1` are narrow A/B fallbacks.

The in-place route produced identical native demo output for tiny, small, and
medium on `line_en`, `line_zh`, `single_word`, and `en`
(`build/average_pool3x2_inplace_cpp_equivalence_20260814.json`). Each model
also retained ORT decoded-text parity on an exact-size line, English page, and
ultra-wide strip (3/3 each;
`build/accuracy_averagepool_inplace_{tiny,small,medium}_20260814.json`).
The current medium resolution-memory ladder passed: it returned from the
pre-return private/working-set peak of **149,241,856 B / 153,153,536 B** to
**143,618,048 B / 147,505,152 B** at final `64x64`.
`build/memory_ladder_medium_cpu_averagepool_inplace_20260814.json` preserves
every resolution sample.

On the local 16-worker CPU, 100-run one-line A/B was positive for medium
(**69.535 -> 68.032 ms**, 2.16%) and within shared-host noise for tiny/small.
It is therefore a verified allocation reduction and a targeted medium
throughput gain, not a uniform speed claim. Raw results:
`build/bench_averagepool_inplace_ab_20260814.json`. The Radeon 780M Vulkan
smoke and hybrid batch parity passed; hybrid continues to admit a Vulkan
segment only after its complete H2D, dispatch, fence, D2H, and CPU comparison
is no slower.

### 2026-08-14: attention QKV vector-copy transpose

The small and medium recognizer attention blocks export a QKV projection as
`[N,T,3,H,D]`, followed by the fixed ONNX permutation
`[2,0,3,1,4] -> [3,N,H,T,D]`.  The innermost head feature vector `D` is
contiguous before and after that permutation.  The executor now copies this
vector with `memcpy` rather than recalculating five-dimensional scalar
coordinates for every float.  All other transposes retain the generic path.
Set `PPOCR_DISABLE_QKV_TRANSPOSE_FASTPATH=1` before constructing OCR to A/B
the generic route.

Decoded-text parity against ONNX Runtime passed on English, Chinese, and
3000x80 ultra-wide inputs for tiny, small, and medium (3/3 for each tier;
`build/accuracy_qkv_transpose_{tiny,small,medium}_20260814.json`). Tiny has
no QKV attention block and remains unaffected. On the local AVX-512 CPU,
the 40-run English-page sample measured small **74.557 -> 70.835 ms**
(5.0%) and medium **217.134 -> 199.390 ms** (8.2%). On the distinct
30-run ultra-wide workload it measured small **44.199 -> 41.999 ms** (5.0%)
and medium **141.816 -> 139.679 ms** (1.5%). The one page measurements are
host-specific; raw records are `build/bench_qkv_transpose_ab_20260814.json`
and `build/bench_qkv_transpose_wide_ab_20260814.json`.

The current medium CPU small-to-4K-to-small ladder stayed bounded: the final
64x64 sample was **143,474,688 B** private / **147,525,632 B** working set,
below both the 4K sample (**146,661,376 B / 150,781,952 B**) and the
pre-return peak.  Full per-resolution evidence is
`build/memory_ladder_medium_cpu_qkv_transpose_20260814.json`.

### 2026-08-14: QKV transpose/slice elimination

The small and medium attention exports immediately split the just-transposed
`[3,N,H,T,D]` QKV activation into three `Slice(1) -> Squeeze(0)` branches.
The loader now recognizes this complete three-branch topology and replaces it
with three direct copies from the original `[N,T,3,H,D]` projection into their
already-squeezed `[N,H,T,D]` destinations. This eliminates the full
transposed QKV activation and the three temporary slice buffers. It is a
strict model-shape fusion; all general Transpose/Slice graphs retain their
ordinary execution. `PPOCR_DISABLE_QKV_SLICE_FUSION=1` is the deployment A/B
fallback.

On the local AVX-512 CPU, the 20-run English-page A/B, with the earlier
vector-copy transpose still enabled in the baseline, measured small
**76.315 -> 72.245 ms** (5.3%) and medium **222.274 -> 195.827 ms** (11.9%).
The baseline values include the prior QKV-vector optimization, so this records
the additional benefit of removing the full transpose/slice lifetime rather
than double-counting it. Raw record:
`build/bench_qkv_slice_fusion_ab_20260814.json`.

The default fused route retained ORT decoded-text parity on English, Chinese,
and 3000x80 ultra-wide input for all three shipped model tiers (3/3 each;
`build/accuracy_qkv_slice_fusion_default_{tiny,small,medium}_20260814.json`).
Tiny has no matching transformer QKV topology and is unchanged. The medium
ascending-resolution memory gate passed: final `64x64` was
**143,544,320 B** private / **151,076,864 B** working set, below the 4K
sample and pre-return peak. Full record:
`build/memory_ladder_medium_cpu_qkv_slice_fusion_20260814.json`. CPU kernel
and Radeon 780M Vulkan smoke also passed; hybrid admission policy remains
unchanged and selects only complete GPU segments that are no slower than CPU.

### 2026-08-14: complete QKV split lifetime and resolution-memory recheck

The three direct Q/K/V copies are now emitted by one `FusedQkvSplit` node
with three outputs.  This keeps the shared `[N,T,3,H,D]` projection live only
until all three final `[N,H,T,D]` tensors have been materialized, then retires
it through the normal use counter.  It is a PP-OCRv6 topology-specific memory
fusion, not general multi-output ONNX runtime support.

The existing native resolution ladder provides the requested ascending image
coverage: `16x16`, `64x64`, `160x120`, `320x240`, `640x480`, `1280x720`,
wide/tall `4096x256` and `256x4096`, `1920x1080`, `2560x1440`, `3000x1600`,
and `3840x2160`, followed by a staged recovery tail and `64x64` return. A
fresh two-cycle medium CPU run passed its 20% bounded-recovery gate. In cycle
1, private / working-set memory declined from **149,700,608 / 153,661,440 B**
at 4K to **147,795,968 / 151,752,704 B** at the immediately following 1080p
page, then finished at **147,509,248 / 151,162,880 B** on the return 64x64.
Cycle 2 likewise declined immediately after 4K; the final small sample was
**147,435,520 / 151,105,536 B**, only **0.27%** above the warmed private-byte
baseline.  Per-resolution evidence is
`build/memory_ladder_medium_cpu_qkv_split_20260814.json`. Windows allocator
capacity is reusable and samples may vary, so the gate verifies bounded
recovery rather than demanding that every allocation be decommitted.

The fused executor also retained decoded-text parity with ONNX Runtime on
English, Chinese, and 3000x80 ultra-wide inputs (3/3 medium cases;
`build/accuracy_qkv_split_default_medium_20260814.json`). CPU kernel and
Radeon 780M Vulkan smoke tests passed after the change.

A final all-tier recheck repeated those three text/diverse-size cases for
tiny, small, and medium (**3/3 each**):
`build/accuracy_qkv_split_{tiny,small,medium}_20260814.json`. The 20-run
CPU snapshot (16 workers, exact GELU) was tiny **30.920 / 21.393 ms**, small
**62.485 / 44.688 ms**, and medium **198.325 / 132.951 ms** for English /
3000x80, respectively (`build/bench_cpu_diverse_qkv_split_20260814.txt`).
The former is timing evidence for this host only; the durable cross-engine
comparison remains the longer, independently measured CPU-versus-ORT corpus.
The final one-cycle 16-sample medium ladder also passed its bounded-return
gate (`build/memory_ladder_medium_cpu_qkv_split_final_20260814.json`), with
the return `64x64` footprint below the pre-return peak. Its immediate 4K
sample did not decline in that isolated Windows run, so the report records
that fact rather than claiming forced allocator decommit.

### 2026-08-14: extended 8K source-image recovery gate

The generated memory corpus now continues beyond 4K with `5120x2880` and
`7680x4320` pages, then immediately processes a `3840x2160` recovery page
before the existing 1080p, extreme-aspect-ratio, and final-`64x64` tail. The
native soak keeps one OCR instance alive but scopes every decoded RGB image to
`load -> Recognize -> destroy -> sample`; this specifically tests source image
release as well as activation reuse. It is intentionally more demanding than
the detector's 960-pixel inference cap, because the decoded 8K source itself
is about 95 MiB.

With medium CPU PP-OCRv6, one strict cycle passed with
`--require-post-large-decline`: private / working-set memory fell from
**149,139,456 / 153,059,328 B** after 8K to **146,808,832 / 150,470,656 B**
at the immediate 4K recovery (**-2,330,624 B / -2,588,672 B**). The final
`64x64` was **147,595,264 / 151,126,016 B**, below the pre-return peaks
(**149,151,744 / 153,059,328 B**) and only **3.03%** above the warmed private
baseline. Full 19-resolution evidence is
`build/memory_ladder_medium_cpu_8k_strict_20260814.json`. This is a
host-specific bounded-recovery observation; it does not promise every Windows
heap or Vulkan driver immediately decommits reusable pages.

### 2026-08-14: reproducible small-to-8K memory ladder

`bench/generate_memory_ladder.py` now creates 19 deterministic P6 PPM pages
in ascending source resolution from `16x16` through `5120x2880` and
`7680x4320`, followed by a `3840x2160 -> 1920x1080 -> wide/tall -> 64x64`
recovery tail. `bench/memory_ladder_regression.py` keeps one native OCR
instance alive, destroys each decoded source image immediately after
recognition, and records private bytes plus working set after every page.

The strict gate compares the 5K/8K high-water with the deliberate post-8K
recovery tail (`4K -> 1080p -> wide/tall`), and independently bounds the
final `64x64` footprint. Windows allocator/working-set accounting is not
guaranteed to be monotonic across adjacent samples, so an optional
`--require-immediate-post-large-decline` diagnostic is available, but the
default strict test requires both counters to fall below the large-page
high-water somewhere in that recovery tail. This avoids presenting sampling
jitter as a leak while still proving that the process returns from a large
page under the same live OCR instance.

### 2026-08-14: recognition-worker lifetime hardening

The production CTC executor no longer stores its compact use-counter vector
or node-input pointer scratch vector in `thread_local` storage.  Those two
small vectors are now invocation-local (the pointer list reserves eight
entries).  This is deliberately a lifetime fix rather than an allocator
cache: on the MinGW/Windows build, CTC execution can run on short-lived outer
recognition workers, and emulated-TLS vector destructors may otherwise be
registered through a different pthread DLL during worker teardown.  The
result was an intermittent `0xC0000374` heap-corruption process exit after a
successful long memory ladder.  Activation tensors themselves remain
per-invocation and are released by the existing graph use-count planner.

The current medium CPU 19-resolution ladder completed and exited cleanly.
Private / working-set memory fell from **149,811,200 / 153,808,896 B** on the
8K source page to **147,935,232 / 151,924,736 B** on its immediate 4K
recovery page; the final `64x64` sample was **143,974,400 / 147,787,776 B**,
only **0.45%** above the warmed private-byte baseline and below the complete
large-page high-water marks.  Full record:
`build/memory_ladder_medium_cpu_8k_tls_fix_20260814.json`.

CPU and hybrid runs both completed the varied `16x16`, English, 3000x80
ultra-wide, and 80x3000 ultra-tall corpus for tiny/small/medium (**12/12 per
backend**): `build/accuracy_tls_lifetime_fix_{cpu,hybrid}_diverse_20260814.json`.
Kernel smoke and Radeon 780M Vulkan smoke also passed. Hybrid retains its
strict per-shape whole-boundary no-slower admission rule; this change does not
claim that the incomplete device-resident OCR graph supports GPU-only mode.

### 2026-08-14: fresh small-to-large memory regression

The checked-in generator and regression gate were rerun against the medium
PP-OCRv6 CPU pipeline.  The deterministic corpus contains 19 PPM inputs:
`16x16 -> 64x64 -> 160x120 -> ... -> 5120x2880 -> 7680x4320`, followed by
`3840x2160 -> 1920x1080 -> wide/tall strips -> 64x64`.  It therefore measures
both normal increasing resolutions and source-image release after the 8K page,
while retaining one OCR instance for the whole sequence.

The strict gate passed for both Private Bytes and Working Set.  The 8K sample
was **148,996,096 / 152,911,872 B**; the immediately following 4K recovery
sample was **147,918,848 / 151,826,432 B** (**-1,077,248 / -1,085,440 B**).
The final 64x64 sample was **143,548,416 / 147,689,472 B**, only **0.25%**
above the warmed Private-Bytes baseline and below the pre-return high-water
mark.  The complete per-resolution record is
`build/memory_ladder_medium_cpu_strict_final_20260814.json`.

Reproduce it with:

```powershell
python bench/generate_memory_ladder.py --output build/memory_ladder_images
python bench/memory_ladder_regression.py --cpp build/ppocr_mem_soak.exe --det D:/workprj/aicoder/.tmp/ocr-models/ppocrv6_medium_det.onnx --rec D:/workprj/aicoder/.tmp/ocr-models/ppocrv6_medium_rec.onnx --dict build/dict_ppocrv6_latin.txt --images build/memory_ladder_images --cycles 1 --backend cpu --require-post-large-decline --report build/memory_ladder_medium_cpu_strict.json
```

### 2026-08-14: current resolution-memory validation

The reproducible ladder was generated again and run with one live medium CPU
OCR instance. It records Private Bytes and Working Set after every one of the
19 pages, with decoded PPM storage destroyed before each sample. The run
passed the bounded-return gate:

| Checkpoint | Private Bytes | Working Set |
| --- | ---: | ---: |
| warmed baseline | 143,437,824 B | 閳?|
| 8K (`7680x4320`) | 148,480,000 B | 152,453,120 B |
| first 4K recovery | 148,000,768 B | 151,769,088 B |
| final `64x64` | 146,055,168 B | 150,097,920 B |

Both counters fell immediately after 8K in this run; the final small image was
**1.82%** above the warmed private-byte baseline and below the complete
pre-return peak. The full per-resolution evidence, including the recovery
tail decision, is
`build/memory_ladder_medium_cpu_strict_current_20260814.json`. Results are
machine/run-specific process accounting, not a fixed cross-platform memory
guarantee.

### 2026-08-14: revalidated varied-resolution memory recovery

The 19-image ascending-and-recovery ladder was regenerated and rerun with one
medium PP-OCRv6 CPU instance (`PPOCR_BENCH_THREADS=16`).  Each PPM is loaded,
recognized, destroyed, and only then sampled, so source RGB storage from a
large page cannot be hidden by retaining the input vector.  The strict
post-large recovery gate passed for both Windows Private Bytes and Working Set:

| Checkpoint | Private Bytes | Working Set |
| --- | ---: | ---: |
| warmed baseline | 142,888,960 B | n/a |
| 5K peak (`5120x2880`) | 148,463,616 B | 152,395,776 B |
| 8K (`7680x4320`) | 146,882,560 B | 151,015,424 B |
| first 4K recovery | 147,435,520 B | 151,506,944 B |
| final `64x64` | 146,251,776 B | 150,216,704 B |

The observed peak was the 5K page rather than 8K, which is valid for Windows
process accounting and the detector's bounded tensor resize.  Both counters
were already below that high-water mark at the first 4K recovery sample; the
final small image remained below it and was 2.35% above the warmed private-byte
baseline.  The machine-specific, per-resolution JSON evidence is
`build/memory_ladder_medium_cpu_strict_revalidated_20260814.json`.

### 2026-08-14: zero-copy top-level ONNX protobuf traversal

Model construction no longer copies the complete embedded ONNX `GraphProto`
before parsing it.  The model reader now exposes bounded protobuf byte spans;
the top-level graph is parsed directly from the already-owned model file buffer.
Nested node, attribute, initializer, and operator-set messages retain their
existing owning parse paths, so the supported PP-OCRv6 graph semantics and
runtime's no-ONNX-Runtime dependency remain unchanged.  This removes one
transient full-model allocation/copy during startup and lowers model-loading
work without altering per-inference numerical operations.

On the local Windows AVX-512 host (`PPOCR_BACKEND=cpu`, 16 kernel workers,
one warm-up and five English-page measurements), constructor-to-ready load
time changed as follows:

| Model | Before | After | Lower load time |
| --- | ---: | ---: | ---: |
| tiny | 27.184 ms | 17.808 ms | 34.5% |
| small | 102.254 ms | 72.066 ms | 29.5% |
| medium | 519.523 ms | 294.587 ms | 43.3% |

The per-model evidence is
`build/bench_model_load_span_parse_ab_20260814.json`; the post-change
inference snapshot is `build/bench_model_load_span_parse_20260814.json`.
Kernel and Vulkan admission smoke passed. CPU and hybrid also completed the
five-size `16x16`, English, low-contrast, ultra-wide, and ultra-tall corpus
for tiny/small/medium (30 successful executions per backend); the recorded
outputs are `build/smoke_span_parse_diverse_{cpu,hybrid}_20260814.json`.
One medium ultra-wide confidence differs only in the last reported digits in
hybrid because its transfer-inclusive channel-affine/depthwise-Swish admission
can select a numerically valid Vulkan segment; decoded text and geometry are
unchanged. GPU-only remains deliberately rejected until the complete graph is
device-resident.

### 2026-08-14: invocation-local executor input scratch reuse

Both the general graph executor and the production CTC executor now reuse one
invocation-local, non-owning node-input pointer vector. Previously, the general
path allocated a separate small vector at each generic operator and at several
in-place fast paths. The new scratch has eight reserved entries (larger future
operator signatures still grow it safely), is never shared across OCR calls,
and retains the existing no-TLS lifetime rule for MinGW worker teardown.

This removes repeated allocator traffic without changing tensors, reduction
order, CPU SIMD dispatch, or the Vulkan admission policy. A fresh CPU English
snapshot (`PPOCR_BENCH_THREADS=16`, two warm-ups, twelve runs) measured
**30.817 / 61.215 / 182.730 ms** for tiny/small/medium. The varied-shape CPU
snapshot additionally completed ultra-wide at **19.090 / 44.437 / 127.590 ms**
and dense `1920x1080` at **265.831 / 1133.132 / 4880.140 ms** (three-run
shared-host samples, therefore directional rather than portability claims).

The 19-resolution medium memory ladder passed again: its 5K high-water was
**149,815,296 / 153,812,992 B** (Private Bytes / Working Set), the first 4K
recovery was **146,288,640 / 150,216,704 B**, and final `64x64` was
**146,501,632 / 150,388,736 B**, still below the pre-return high-water. The
complete evidence is `build/memory_ladder_medium_cpu_input_scratch_reuse_20260814.json`.
All 15 tiny/small/medium varied-size cases completed in both CPU and hybrid;
their decoded text and geometry agree across backends. Kernel and Radeon 780M
Vulkan admission smokes passed, with channel-affine Swish and depthwise-Swish
still selected only when measured full-boundary GPU cost is no slower than CPU.
Records: `build/bench_input_scratch_reuse_{en,diverse}_20260814.json` and
`build/smoke_input_scratch_reuse_diverse_{cpu,hybrid}_20260814.json`.

### 2026-08-14: small-to-large image memory recovery regression

The repository includes a native process-memory regression for long-lived OCR
services. `bench/generate_memory_ladder.py` produces deterministic PPM pages
that increase from `16x16` through `7680x4320`, including wide and tall
aspect-ratio cases, then process a staged `4K -> 1080p -> wide/tall -> 64x64`
recovery tail. `bench/memory_ladder_regression.py` keeps one OCR instance alive
and records Windows Private Bytes and Working Set after every resolution.

Run the full test with:

```powershell
$env:PPOCR_BENCH_THREADS = '16'
python bench/generate_memory_ladder.py --output build/memory_ladder_images
python bench/memory_ladder_regression.py `
  --cpp build/ppocr_mem_soak.exe `
  --det D:/workprj/aicoder/.tmp/ocr-models/ppocrv6_medium_det.onnx `
  --rec D:/workprj/aicoder/.tmp/ocr-models/ppocrv6_medium_rec.onnx `
  --dict build/dict_ppocrv6_latin.txt `
  --images build/memory_ladder_images --cycles 1 --backend cpu `
  --require-post-large-decline `
  --report build/memory_ladder_medium_cpu_compact_uses_20260814.json
```

On the current Windows x86 host, the test passed after the compact executor
use-count change. The `7680x4320` sample reached **150,474,752 B / 154,353,664
B** (Private Bytes / Working Set). The recovery tail fell to **147,111,936 B /
151,142,400 B** at `1920x1080`, and the final `64x64` checkpoint was
**148,066,304 B / 151,736,320 B**. Thus both counters declined below the
post-large high-water without restarting the OCR instance. The adjacent first
4K recovery measurement may briefly exceed the 8K sample because of Windows
allocator/working-set accounting; the enforced gate intentionally verifies a
decline in the complete post-large recovery tail instead of claiming a brittle
single-sample monotonic property. Full per-resolution evidence is
`build/memory_ladder_medium_cpu_compact_uses_20260814.json`.

### 2026-08-14: refreshed exact detector batching across three model sizes

The true same-shape detector NCHW batch was rerun after the memory work with
four copies of the English page. The check compares every text, quadrilateral,
bounding box, and confidence against four serial calls. Recognition retained
`rec_batch_size=1`: an investigation confirmed that forcing four recognizer
crops through the transformer can change exact CTC confidence on this host, so
it is not used for the exact-output benchmark.

With `PPOCR_BENCH_THREADS=16`, `PPOCR_DET_BATCH_SIZE=4`,
`PPOCR_REC_BATCH_SIZE=1`, and `PPOCR_BATCH_PREPROCESS_PARALLELISM=4`, the
three-run means were:

| Model | CPU serial | CPU batch | CPU speedup | Hybrid serial | Hybrid batch | Hybrid speedup |
| --- | ---: | ---: | ---: | ---: | ---: | ---: |
| tiny | 133.272 ms | 76.211 ms | 1.749x | 157.468 ms | 128.652 ms | 1.224x |
| small | 282.395 ms | 177.486 ms | 1.591x | 442.434 ms | 390.907 ms | 1.132x |
| medium | 1241.956 ms | 1013.146 ms | 1.226x | 1230.259 ms | 1138.408 ms | 1.081x |

The corresponding exact-parity record is
`build/batch_detector_rec1_current_20260814.json`. Hybrid remains an
honest per-segment policy: Vulkan is selected only when the full measured
host-to-device, dispatch, and device-to-host boundary is no slower than CPU;
on this Radeon 780M run, small channel-affine Swish and depthwise-Swish
segments met that rule while the remainder correctly stayed on SIMD CPU.

### 2026-08-14: verified four-page detector NCHW batching

`RecognizeBatch()` was rechecked on four same-shape English pages for every
PP-OCRv6 tier.  The detector receives one real `[4,3,H,W]` tensor; each
result, including text, quadrilateral, bounding box, and confidence, was
checked against four serial `Recognize()` calls by `ppocr_batch_smoke`.
Recognition remains `rec_batch_size=1` in this comparison: packing unequal
recognizer widths by right-padding changes transformer attention and can alter
CTC confidence, so it is not represented as exact-output acceleration.

With 16 CPU workers, `det_batch_size=4`, four preprocessing workers, one
warm-up, and five measured CPU iterations, serial-to-batch time was:

| Model | Serial mean | Batched mean | Throughput gain |
|---|---:|---:|---:|
| tiny | 146.914 ms | 86.413 ms | 1.700x |
| small | 318.376 ms | 204.255 ms | 1.559x |
| medium | 1289.731 ms | 1011.596 ms | 1.275x |

The corresponding hybrid recheck (three iterations; the same exact-output
gate) measured **1.218x / 1.138x / 1.079x** for tiny/small/medium. Hybrid
still admits each Vulkan segment only after its complete H2D + shader + D2H
path is no slower than the matching CPU path; this is not a claim that the
incomplete full graph supports `gpu_only`. The host-specific full record is
`build/bench_batch_detector_nchw_current_20260814.json`.

Reproduce the CPU measurement with:

```powershell
$env:PPOCR_BACKEND='cpu'; $env:PPOCR_BENCH_THREADS='16'
$env:PPOCR_DET_BATCH_SIZE='4'; $env:PPOCR_REC_BATCH_SIZE='1'
$env:PPOCR_BATCH_PREPROCESS_PARALLELISM='4'; $env:PPOCR_BATCH_WARMUP='1'; $env:PPOCR_BATCH_RUNS='5'
.\build\ppocr_batch_smoke.exe DET.onnx REC.onnx dict.txt 1 en.ppm en.ppm en.ppm en.ppm
```

### 2026-08-13: Vulkan ConvTranspose + Add primitive groundwork

The Vulkan backend now has a numerically tested `ConvTranspose(2x2,
stride=2) + equal-shape Add` primitive. It keeps the projection in device
buffer D, inserts a compute write/read barrier, adds the residual in a second
dispatch, and copies only the final sum back. Its hybrid admission is strict:
it measures and validates complete `H2D + two dispatches + fence + D2H`
against the matching CPU SIMD sequence, then selects Vulkan only when no
slower.

On this Radeon 780M test shape (`N=4, Cin=32, Cout=40, 31x29`), GPU was
**2.771 ms** versus CPU **0.535 ms**, so CPU correctly remains selected. This
is backend coverage, not an end-to-end GPU speed claim. The current PP-OCRv6
FPN export folds its following `[1,C,1,1]` Add into the transpose bias, so the
new equal-shape-residual primitive is intentionally not claimed as active for
that model revision. `ppocr_vulkan_smoke` covers it; tiny/small/medium CPU
text parity passed **2/2** each on `en.ppm` and `wide_strip_3000x80.ppm`,
recorded in `build/accuracy_{tiny,small,medium}_convtranspose_add_20260813.json`.

## Build

### 2026-08-14: compact execution liveness and resolution-memory revalidation

The detector's generic executor now resets compact `uint16_t` use counters
indexed once at model load, rather than cloning a string-keyed use-count map
for every page. This removes per-inference hash-table bookkeeping while
retaining the existing last-use tensor release rules. The change applies only
to the fixed PP-OCRv6 graph topology; arbitrary graph values still retain
their original tensor ownership and output semantics.

The CPU multi-size smoke completed tiny/small/medium over five distinct
shapes (`16x16`, English, ultra-wide, ultra-tall, and dense `1920x1080`). The
record is `build/bench_diverse_compact_uses_20260814.json`; its three-run
means are intentionally retained as per-host measurement evidence rather than
portable speed claims. Kernel and Radeon 780M Vulkan admission smokes also
passed. Hybrid retains its full transfer-inclusive rule: a Vulkan segment is
used only after measured `H2D + GPU + D2H` is no slower than the same CPU
segment. GPU-only remains deliberately rejected because the complete graph is
not yet device-resident.

The 19-resolution medium CPU ladder was revalidated with one OCR instance
alive throughout. It passed `--require-post-large-decline`: the `7680x4320`
sample measured **147,972,096 B / 151,748,608 B** (Private Bytes / Working
Set), then the recovery tail reached **146,042,880 B / 148,320,256 B** at the
wide `4096x256` sample. The final `64x64` checkpoint was **147,783,680 B /
151,691,264 B**, below the largest-image private-byte value and below the
pre-return high-water. Full per-resolution evidence is
`build/memory_ladder_medium_cpu_compact_uses_final_20260814.json`.

### 2026-08-14: current ascending-resolution memory regression

The same long-lived medium CPU instance was rerun over all 19 generated
images, in ascending source sizes from `16x16` to `7680x4320`, followed by
`3840x2160 -> 1920x1080 -> 4096x256 -> 256x4096 -> 64x64`.  Each page is
scoped to `load -> Recognize -> destroy -> sample`, so the measurements expose
both inference activation reuse and whether a decoded large source image stays
resident after its OCR call.

The strict recovery gate passed.  At 8K, Private Bytes / Working Set were
**148,131,840 B / 152,174,592 B**.  The immediately following 4K page was
**147,681,280 B / 151,670,784 B**, a drop of **450,560 B / 503,808 B**.  The
final `64x64` checkpoint was **147,587,072 B / 151,429,120 B**, below both the
8K sample and the pre-return high-water (**150,106,112 B / 154,062,848 B**),
without recreating the OCR instance.  Per-resolution samples and the enforced
pass/fail decision are recorded in
`build/memory_ladder_medium_cpu_current_resolution_recovery_20260814.json`.


### 2026-08-14: refreshed three-tier CPU / Hybrid comparison

`bench/compare.ps1` now accepts `-Backend cpu|hybrid|gpu` and passes the
choice through to the native benchmark. This makes the CPU and Hybrid runs
explicit in the same ONNX Runtime comparison harness instead of inheriting an
ambient process environment.

On the local AVX-512 host, `en.ppm`, 2 warm-ups and 6 measured runs, the
native CPU implementation measured **32.315 ms** (tiny) and **67.419 ms**
(small), versus ONNX Runtime CPUExecutionProvider **113.453 ms** and
**149.804 ms**: **71.5%** and **55.0%** lower mean latency respectively. The
same harness measured medium Hybrid at **239.765 ms** versus ONNX Runtime
**333.395 ms** (**28.1%** lower). These are machine/run-specific samples;
reproduce before treating them as deployment guarantees.

The medium high-density `dense_blobs` stress bound was refreshed to
`[100, 3600]`. The current native medium detector produced 2,903 valid
components and the full 11-image varied-size stress suite passed.

### 2026-08-14: terminal CTC projection is now the default

The recognizer's final vocabulary projection is now executed through the
bounded `GemmCtcTop1` route by default. It computes each small time-step tile,
performs the CTC argmax/probability reduction, and releases that tile rather
than materializing the full `[N,T,V]` logit tensor. Set
`PPOCR_DISABLE_FUSED_TERMINAL_CTC=1` only for an A/B comparison with the older
materialized-logit route.

On the dense `ui_dense_1920x1080` corpus the default route reduced measured
CPU latency in this local run from **279.538 to 263.995 ms** for tiny
(123 crops), **1077.122 to 965.587 ms** for small (119 crops), and
**6285.383 to 5621.346 ms** for medium (122 crops). These samples are
machine-specific; text parity against ONNX Runtime passed 4/4 varied inputs
for each model after enabling the default.

### 2026-08-14: refreshed 16x16-to-8K memory recovery measurement

The deterministic 19-image ladder was rerun with one live medium CPU OCR
instance. It processes ascending source resolutions from `16x16` through
`7680x4320`, then a `3840x2160 -> 1920x1080 -> 4096x256 -> 256x4096 ->
64x64` recovery tail. Every input is scoped to `load -> Recognize -> destroy
-> sample`, so this measures both activation reuse and release of a large
decoded RGB source image.

The strict post-large recovery gate passed. The 5K/8K high-water was
**150,675,456 B / 154,615,808 B** (Private Bytes / Working Set); the first
4K recovery sample was **150,036,480 B / 154,087,424 B**, and the final
`64x64` sample was **148,877,312 B / 151,830,528 B**. The final small-image
footprint was 3.63% above the warmed private-byte baseline and below both
pre-return peaks, confirming bounded memory recovery without recreating the
OCR instance. Full per-resolution evidence is
`build/memory_ladder_medium_cpu_post_large_20260814.json`. Windows allocator
accounting may fluctuate between adjacent samples; the enforced condition is
that both counters return below the 5K/8K high-water somewhere in the
post-large recovery tail.
### 2026-08-14: CTC tile-policy validation and final memory recheck

The four-row bounded terminal-CTC projection remains the default. An
experimental automatic eight-row choice for the wider recognizers was tested
on the high-density `1920x1080` sample, but was slower in the paired local
runs: small measured **914.427 ms** versus **897.369 ms** with four rows, and
medium measured **4829.971 ms** versus **4529.301 ms**. The larger tile
remains available only through `PPOCR_FUSED_TERMINAL_CTC_TILE_ROWS` for
platform-specific experiments; it is not used as the portable default.

After this decision, the complete 19-resolution medium CPU memory check
passed again. Private Bytes / Working Set fell from **147,623,936 B /
151,322,624 B** at the 8K sample to **146,046,976 B / 149,807,104 B** at the
first 4K recovery; final `64x64` was **143,917,056 B / 147,906,560 B**
(**0.04%** above the warmed private-byte baseline), below the full pre-return
high-water. The durable per-resolution record is
`build/memory_ladder_medium_cpu_tile4_20260814.json`.
### 2026-08-14: recognizer hotspot profiling and Vulkan Hybrid revalidation

`PPOCR_PROFILE=1` now reports the terminal-CTC executor even when its fused
`GemmCtcTop1` path returns early. On the medium ultra-wide crop, that direct
measurement identifies the terminal vocabulary projection as the largest
recognizer operation (**40.456 ms** in this local profile), followed by the
existing fused 1x1/residual convolutions. This makes future optimization work
measurable instead of inferring recognizer cost from detector-only profiles.

The Vulkan Hybrid policy was revalidated on AMD Radeon 780M. It measures each
implemented segment as a complete synchronous `H2D + dispatch + D2H` path and
selects GPU on `gpu_mean <= cpu_mean`; smoke selected GPU for channel-affine
Swish (**0.193 vs 0.404 ms**) and depthwise-Swish (**0.341 vs 0.346 ms**),
while transfer-bound primitives correctly remained on CPU. Tiny, small, and
medium Hybrid text parity all passed on normal and ultra-wide inputs (6/6).
GPU-only remains deliberately unavailable until the complete detector,
recognizer, and post-processing graph is device-resident; it does not silently
fall back to CPU.

The AVX-512 four-row GEMM microkernel was also retested against the stable
two-row default. It remains an explicit
`PPOCR_ENABLE_AVX512_GEMM4ROW=1` deployment A/B option only: its effect varied
between otherwise similar paired runs, so it is not enabled by default.

### 2026-08-14: medium terminal-CTC projection parallelism

The terminal CTC projection now uses a bounded **32-row** vocabulary tile for
the medium recognizer (`depth >= 384`, `vocab >= 1024`); tiny and small retain
the prior four-row tile. This gives a single ultra-wide medium crop enough
independent GEMM rows to use the persistent SIMD pool, while keeping CTC
blank/repeat state serial in time order and the workspace bounded. The
`PPOCR_FUSED_TERMINAL_CTC_TILE_ROWS=1|2|4|8|16|32` override remains available
for deployment-side A/B.

On this AVX-512 Windows host (16 workers), paired ultra-wide `3000x80`
measurements improved medium from **189.408 ms** (four rows) to **150.969 ms**
(32 rows), a **20.3%** reduction; small improved from **61.882 to 56.759 ms**
in that isolated wide test, but dense-page runs were less stable, so its
conservative default remains four rows. Medium dense `1920x1080` also improved
from **5237.145 to 4671.601 ms** in the paired run. These figures are local
host measurements, not portable latency guarantees.

The associated 19-resolution medium CPU memory gate passed: 8K was
**150,437,888 B / 154,501,120 B** (Private Bytes / Working Set), immediate
4K recovery was **148,398,080 B / 152,215,552 B**, and final `64x64` was
**144,076,800 B / 148,070,400 B**, below baseline and all large-page
high-water marks. Per-resolution evidence:
`build/memory_ladder_medium_cpu_ctc32_20260814.json`.

The same gate was rerun after the final CTC policy validation. It again
passed the enforced `--require-post-large-decline` condition: the 5K/8K
high-water was **149,454,848 B / 153,169,920 B**, the first post-8K 4K page
fell to **146,534,400 B / 150,233,088 B**, and the final `64x64` checkpoint
was **147,755,008 B / 151,703,552 B**. This is **0.37%** above the warmed
**147,210,240 B** private-byte baseline and below both pre-return peaks, so
large decoded images and inference workspaces do not remain pinned after the
large-image sequence. The ladder deliberately covers 19 inputs from `16x16`
through `7680x4320`, including wide/tall aspect-ratio branches and a staged
`4K -> 1080p -> wide -> tall -> 64x64` recovery tail. Full JSON evidence:
`build/memory_ladder_medium_cpu_ctc32_recheck_20260814.json`.

### 2026-08-14: CTC workspace reuse experiment rejected

A CTC vocabulary-tile reuse experiment was measured on the 123/119/122-crop
dense `1920x1080` page. Sharing one preallocated tile per in-flight sequence
increased the medium batch workspace enough to cause a memory-recovery gate
failure on one fresh run, while its latency did not improve reliably. The
production implementation therefore retains a short-lived, per-worker bounded
tile: it has a strict `32 * vocab`-float cap for medium and `4 * vocab` for
tiny/small, releases promptly after each recognition task, and avoids unsafe
MinGW thread-local destructors. This choice is deliberately evidence-led: the
restored implementation passed the 19-resolution CPU memory gate again, with
the first recovery-tail point below the 8K private/working-set high-water at
`1920x1080` (**146,456,576 B / 149,090,304 B**) and final `64x64` still below
the pre-return peak. Evidence:
`build/memory_ladder_medium_cpu_ctc_workspace_reverted_20260814.json`.

### 2026-08-14: hardware-aware recognition worker bound

The 12-way CPU recognition default is capped at
`std::thread::hardware_concurrency()`. This retains the measured 12-way
policy on the local 16-logical-core AVX-512 machine while preventing a small
x86 or ARM target from constructing more independent crop graphs than its
available logical CPUs. Hybrid deliberately keeps its separate
`hybrid_graph_parallelism` policy because its Vulkan queue is serialized. The
public `PPOCR_REC_PARALLELISM` override remains available for host-specific
tuning.

### 2026-08-14: dense-page recognition scheduler tuning

The CPU default `rec_parallelism` is now **12** (override with
`PPOCR_REC_PARALLELISM`). A 16-worker AVX-512 sweep on the 123/119/122-crop
dense `1920x1080` page measured 8-way versus 12-way versus 16-way outer
recognition scheduling. Twelve was the stable cross-model choice: tiny
improved from **282.675 to 241.928 ms** (14.4%), small from **949.373 to
**885.617 ms** (6.7%), and medium from **3968.286 to 3905.875 ms** (1.6%).
At 16 ways medium regressed to **4375.612 ms**, so the default deliberately
leaves headroom for its larger SIMD kernels and avoids multiplying dense-page
activation lifetime further.

A fresh default run measured **236.679 / 854.346 / 4136.895 ms** for
tiny/small/medium respectively (3/3, 3/3, and 2/2 measured samples). Normal
and ultra-wide decoded-text parity against ORT remained 6/6. The 19-resolution
medium memory gate also passed: after the 8K page, Private Bytes / Working
Set fell from **149,106,688 / 153,096,192 B** to **147,845,120 /
151,638,016 B** at the first 4K recovery page; the final `64x64` checkpoint
remained below the large-page high-water. Evidence:
`build/memory_ladder_medium_cpu_recparallel12_20260814.json`.

### 2026-08-14: multi-image native/ORT gate repair and revalidation

`bench/compare_models.ps1` now reliably expands a comma-separated or native
PowerShell `string[]` image list, forwards the selected CPU/Hybrid backend,
and distinguishes a latency-weighted corpus gate from an explicit per-case
floor. This prevents a one-image invocation from being presented as a
multi-resolution result and makes each model/image pair independently auditable.

A fresh CPU validation used normal English and ultra-wide `3000x80` text,
16 workers, one warm-up, two timed runs, and required every one of the six
model/image pairs to beat ONNX Runtime CPU. All passed. The latency-weighted
native reductions were **68.1%** (tiny), **56.2%** (small), and **22.9%**
(medium); no model had a losing case in this run. Full machine-specific
evidence: `build/compare_models_cpu_normal_wide_gate_20260814.json`.

The same wrapper also supports `-Backend hybrid`; on this Radeon 780M UMA
host, it preserves the transfer-inclusive Vulkan admission policy rather than
claiming universal end-to-end GPU gains.

### 2026-08-14: refreshed three-tier ONNX Runtime comparison

The current 16-worker CPU comparison (2 warm-ups, 6 measured `en.ppm` runs)
continues to show substantial native gains over ONNX Runtime CPUExecutionProvider:
**33.084 vs 118.015 ms** for tiny (**72.0% lower**), **72.522 vs 195.894 ms**
for small (**63.0% lower**), and **222.385 vs 402.871 ms** for medium
(**44.8% lower**). These are paired local-host measurements and include the
complete native OCR pipeline, not an isolated kernel claim.

An additional selected-class CTC-softmax parallelization experiment was
rejected: it was neutral on a single wide crop and slower on a dense medium
page, so the shipped path retains the lower-variance temporal CTC scan.
Hybrid text parity was rerun for tiny/small/medium on normal and ultra-wide
inputs (6/6); the GPU decision rule remains unchanged: choose Vulkan only
when the complete transfer-inclusive segment is no slower than CPU.

### 2026-08-14: Vulkan device-resident graph foundation

The Vulkan backend now has a `VulkanTensorArena` separate from Hybrid's five
short-lived scratch bindings. It allocates FP32 storage slots by tensor size,
reuses a released slot only after the caller's final-use decision, and reports
live versus retained capacity. Graph boundaries can upload inputs/constants
and download requested outputs, while intermediate elementwise values remain
in Vulkan buffers. The first device-resident operators are exact binary
in-place updates and the NCHW 1x1 Conv family used throughout the recognizer;
both insert compute write-to-read barriers before their output can feed the
next graph node.

The Radeon 780M Vulkan smoke now verifies slot allocation/reuse, upload,
device binary and dependent binary-chain execution, plus device-resident
pointwise convolution against CPU FP32 reference values. The regular SIMD and
all existing Hybrid primitives remain covered. This is infrastructure for the
complete GPU-only graph, not a claim that `gpu_only` is available yet: pool,
LayerNorm, attention Softmax/QKV, transposes, concatenation, detector DB
post-processing, and remaining graph dispatches still need device paths.

### 2026-08-14: GPU-only graph operator expansion

The device arena now additionally supports a real destination-writing NCHW
suffix broadcast (`[N,C,H,W]` with compact `[C,1,1]` coefficients) and exact
Erf-form GELU on the shader. Both are numerically checked by
`ppocr_vulkan_smoke` on the AMD Radeon 780M; neither reads an intermediate
activation back through the CPU. The broadcast form is required for SE gates
and compact graph scale paths, while exact GELU covers a fused-model operator
present in every supported detector/recognizer pair.

This does **not** enable `--backend gpu`: the complete graph still lacks
device implementations for graph concatenation/shape-slice metadata handling,
unfused resize forms, SE composition, and the full OCR image/DB/CTC pipeline.
Construction continues to fail explicitly rather than silently executing an
activation on CPU. No end-to-end GPU-only benchmark is recorded until that
contract can be exercised and compared fairly.

The same arena now includes device-resident two-to-four input `Concat` and
integer-factor asymmetric/floor nearest `Resize` (including unequal height /
width factors). These are validated with multi-outer-block and `N=2` smoke
cases. They remove two more detector-FPN activation boundaries; they do not
change the strict GPU-only availability gate because a complete model graph
and OCR front/back-end still require verified device dispatches.

Medium-model SE is now represented as one device-resident arena routine:
spatial mean, both 1x1 projections, ReLU, HardSigmoid, and final channel
multiply all remain in Vulkan buffers. The Radeon smoke checks every output
against an independent FP32 reference for `N=2,C=4,reduced-C=3,plane=13`.

The ONNX executor now also has a strict Vulkan graph-execution scaffold with
device value metadata, graph-use-count slot reclamation, device copy for
branch fan-out, metadata-only reshape/squeeze/unsqueeze, pointwise unary and
binary aliases, Concat, and fused SE routing. It returns failure immediately
on an uncovered graph node; the public GPU-only gate remains closed until the
entire detector, recognizer, and OCR pipeline can use that path.

The strict graph executor now maps normal/fused NCHW Conv and Max/AveragePool
to their device-arena implementations. When an activation fan-out prevents an
in-place update, it first uses the new GPU copy primitive; this preserves
graph arithmetic rather than overwriting a still-live branch. Unsupported
geometry or nodes still terminate GPU-only execution instead of invoking CPU.

### 2026-08-15: strict Vulkan graph coverage extended

The strict device graph now also covers detector depthwise/pointwise blocks,
residual 1x1 projections, compact SE-style broadcasts, spatial means,
integer nearest resize and resize-add, 2x2 stride-two transpose convolution,
SAME padding for Conv/Pool, inference BatchNorm channel-affine, rank 2--4
transpose, and final matrix projection/Softmax. `FusedConvHardSigmoid` was
corrected to run its exported alpha/beta activation as a separate Vulkan unary
after convolution; it no longer risks returning an ungated Conv result.

`ppocr_gpu_graph_smoke` was added as a direct CPU-versus-strict-device graph
tool. It deliberately does not mark public `gpu_only` OCR as available: the
full image preprocessing, DB detector postprocessing, crop generation and
CTC decoding must still be moved onto Vulkan before that user-facing contract
can be truthfully enabled. On 2026-08-15 the Radeon 780M low-level Vulkan and
SIMD smoke suites passed; full-graph parity is still gated while the remaining
recognizer attention nodes and final numerical-error envelope are completed.

### 2026-08-15: GPU-only recognizer scheduling progress

The strict Vulkan executor now runs the PP-OCRv6 small/medium recognizer's
dynamic shape-metadata chains (`Shape`/`Slice`/`Squeeze`/`Unsqueeze`/`Concat`),
scalar attention scale, fused QKV split, rank-3/rank-4 attention `MatMul`,
Softmax, and residual transformer blocks without downloading an activation.
Only integer shape descriptors are interpreted on the host; feature maps stay
in arena buffers. The generic GEMM path is the current correctness baseline;
the experimental tiled GEMM requires `PPOCR_ENABLE_VULKAN_GEMM_TILE=1`.

Verification on the AMD Radeon 780M: `ppocr_vulkan_smoke` and
`ppocr_kernel_smoke` pass, and the normal tiny Hybrid OCR benchmark remained
functional at **10.775 ms** mean over two measured runs on `line_en.ppm`.
The ordinary-Conv shared-memory route is now gated by the same large-output
threshold in host dispatch and shader dispatch. Previously a compact SE gate
could be launched through the generic host geometry but interpreted as a
channel-tiled shader geometry, leaving stale arena values. With that mismatch
removed, strict CPU-versus-Vulkan forward parity now passes for every shipped
network on the Radeon 780M: tiny/small/medium detector at `1x3x960x960`, and
tiny/small/medium recognizer at `1x3x48x320`. The largest observed final
absolute errors are `2.42644e-06`, `6.57933e-06`, and `7.00675e-09` for the
detectors, and `5.88894e-05`, `2.09391e-04`, and `8.39829e-05` for the
recognizers, respectively.

`ppocr_gpu_graph_smoke` now accepts an optional `RUNS` argument and prints
CPU/GPU graph means, including the current GPU graph boundary. The initial
two-run reference on this UMA Radeon machine measured tiny detector
`124.284 / 610.187 ms`, tiny recognizer `8.190 / 173.200 ms`, small detector
`219.862 / 1613.830 ms`, small recognizer `20.697 / 370.361 ms`, medium
detector `1033.580 / 8530.580 ms`, and medium recognizer `33.085 / 577.311
ms` (CPU / strict Vulkan). These are correctness-baseline measurements, not
a GPU speed claim: each current graph operator submits and waits separately,
so command-batch compilation and persistent model constants are the next
Vulkan performance work.

### 2026-08-15: strict graph single-submit command recording

The strict neural Vulkan executor now records a complete forward graph into
one command buffer and waits only at its output boundary. Every dispatch gets
an immutable descriptor set from a dedicated resettable graph pool, preventing
later descriptor writes from changing earlier recorded bindings. Hybrid keeps
its original synchronous descriptor pool and full-boundary admission policy.

The local Radeon 780M verification passed the Vulkan primitive suite, SIMD
kernel suite, and all six strict graph parity cases at the published shapes.
The current two-run CPU / Vulkan means are tiny detector **223.271 / 1042.440
ms**, tiny recognizer **29.517 / 319.981 ms**, small detector **195.110 /
1249.390 ms**, small recognizer **18.378 / 291.485 ms**, medium detector
**812.492 / 10669.200 ms**, and medium recognizer **39.293 / 564.885 ms**.
Final tensor parity was exact in these runs (max absolute error `0`). The UMA
driver still makes this graph implementation slower than the AVX-512 CPU
baseline; eliminating submission fences alone is not enough to claim a
speedup, so the public GPU-only OCR contract remains closed.

### 2026-08-15: persistent GPU model weights and lower Conv tile threshold

Strict `OnnxLite` GPU models now retain their immutable initializer slots in a
model-owned Vulkan arena. Activations are released after every successful or
failed run, and the arena is guarded for the complete graph recording; this
removes repeated model-weight allocation/upload and prevents per-inference
arena growth. The ordinary-Conv shared-filter tile threshold was lowered from
16,384 to 4,096 output pixels in both host and shader dispatch logic, while
retaining the compact SE fallback path.

With a warmed model, Radeon 780M three-run strict graph means were **tiny
detector 111.399 / 264.214 ms**, **small detector 229.969 / 858.226 ms**,
**medium detector 820.237 / 8059.020 ms** (medium: two runs), **tiny
recognizer 7.915 / 86.976 ms**, **small recognizer 18.101 / 122.982 ms**, and
**medium recognizer 34.873 / 354.897 ms** (CPU / Vulkan). Exact parity held
for all six models. The tiny detector resolution ladder also passed at
`320²`, `640²`, and `960²` with zero final error; warmed Vulkan means were
**40.471**, **109.382**, and **264.214 ms**, respectively. A real `N=4`
tiny-recognizer batch at `4x3x48x320` also remained exactly equal to CPU.

These results are a substantial reduction of strict-device scheduling and
weight-transfer overhead, but this Radeon 780M UMA configuration is still not
faster than its AVX-512 CPU path for complete PP-OCRv6 graphs. Hybrid retains
its measured per-segment policy: when Vulkan is equal or faster for the full
boundary it is selected, otherwise CPU is retained to avoid consuming GPU
time without a latency benefit.

### 2026-08-15: expanded Conv tile range

The ordinary-Conv shared-weight tile is now eligible from a `256`-pixel
output plane (host and SPIR-V use the same gate), extending reuse to smaller
detector feature maps without changing compact SE convolutions. The regenerated
shader and strict graph test passed with final error `0` on tiny detector
`320x320` and `960x960`; warmed Vulkan means were **37.13 ms** and
**236.52 ms**, respectively. Lowering the threshold again to `64` regressed
both shapes, so `256` is retained.

### 2026-08-15: GPU-only front/back-end groundwork

The Vulkan arena now has a live-slot graph handoff API, fused BatchNorm+Swish
dispatch, RGB bilinear-resize+NCHW-normalization shader, device threshold-mask
shader, and device CTC Top-1 reduction. `ppocr_gpu_frontend_smoke` verifies
the RGB path on Radeon 780M; its maximum detector-normalized difference from
the scalar front-end was **0.0175072**, below one source uint8 normalization
step. The strict tiny detector and recognizer graph regressions remained exact
at their final tensors.

This is deliberately not advertised as a completed public GPU-only OCR mode:
DB box scores/unclip parity and whole-image decoded-text parity still require
an end-to-end validation suite. Accordingly `Backend::gpu_only` continues to
fail explicitly rather than returning potentially different OCR results. The
experimental device orchestration never falls back to the CPU NN executor,
but it is not enabled through the public API until that parity evidence exists.

### 2026-08-15: strict graph memory ladder and default recognizer GEMM tile

`ppocr_gpu_graph_mem_soak` is a new model-level Vulkan memory regression tool.
It warms one model, drives it through an ascending resolution/batch ladder,
then repeats a small input and reports both allocated arena capacity and live
bytes. Capacity is deliberately reusable high-water storage; the required
invariant is that live bytes return to the model's persistent-weights baseline
after every run.

On the Radeon 780M, tiny detector `320x320 -> 640x640 -> 960x960 -> 320x320`
grew capacity to **214,007,808 bytes** while live bytes returned after every
sample to **1,713,620 bytes**. Tiny recognizer
`1x3x48x80 -> 1x3x48x320 -> 4x3x48x320 -> 8x3x48x640 -> 1x3x48x80` reached
**67,633,152 bytes** and recovered each time to **4,417,112 bytes**. The
same invariant passed on small detector (**303,267,840 / 9,813,412 bytes**)
and medium recognizer (**191,889,408 / 76,456,032 bytes** capacity/live
baseline). This explicitly covers both varied detector images and recognition
batch/width growth without retaining dynamic activations after a large run.

The verified non-Swish strict-graph GEMM tile is now default-enabled for
`rows >= 8, depth >= 16, columns >= 128`; set
`PPOCR_DISABLE_VULKAN_GEMM_TILE=1` for an A/B fallback. On the same host,
final tensor parity remained exactly zero for all three recognizers. The
current short strict-recognizer means at `1x3x48x320` were tiny
**9.869 / 37.195 ms**, small **23.498 / 107.000 ms**, and medium
**45.271 / 389.620 ms** (CPU / Vulkan). This is an improvement for the
device graph but not a claim that this AVX-512 + Radeon 780M UMA system beats
CPU or ONNX Runtime end-to-end; Hybrid still uses its full-boundary
no-slower admission rule.

### 2026-08-15: parallel Softmax writeback

The strict Vulkan Softmax now retains its sequential max/sum reduction for
numerical stability, then spreads the independent exponential/writeback stage
across the 256-lane workgroup. This removes a serial device loop in
recognizer attention and terminal class Softmax without adding an activation
allocation. Final tensor parity remained **0** for tiny, small, and medium
recognizers at `1x3x48x320`, and at a real `4x3x48x320` batch. The short
post-change means were tiny **37.470 ms**, small **94.376 ms**, and medium
**382.981 ms** for the single-crop strict Vulkan graph; the small recognizer
improved from the preceding **107.000 ms** sample. Device output is still
slower than the local AVX-512 CPU baseline, so this is a verified incremental
improvement rather than an ONNX Runtime superiority claim.

The public `gpu_only` OCR switch remains deliberately disabled. Image resize
and normalization upload, DB connected-component/unclip postprocessing, crop
generation, CTC top-1/decode, end-to-end output parity, and memory recovery
must be completed before the public contract can truthfully promise complete
GPU-only OCR.

### 2026-08-15: device-resident OCR path validation gate

The experimental OCR route now feeds strict Vulkan detector/recognizer graphs
from the fused Vulkan RGB resize, BGR conversion and normalization dispatch;
it no longer builds detector or recognizer NCHW activations with CPU floating
point code. Detector probabilities are downloaded for the existing DB
connected-component/score/unclip control path, and only compact CTC Top-1
metadata is downloaded for string assembly. `ppocr_gpu_ocr_smoke` compares
the public OCR result (text, quad, bounding rectangle and confidence) with
CPU-only OCR.

On the Radeon 780M, tiny and small models passed `en.ppm`, `line_en.ppm` and
`mixed.ppm` (6 decoded regions each), with maximum confidence differences
of **0.0000061** and **0.0000019**, respectively. Tiny also passed `en.ppm`
alone at **0.0000026**. These runs establish that the NN graph has no silent
CPU operator fallback, but do not establish complete release coverage:
the dense 1920x1080 page diverged in detector/recognizer results (tiny result
72; small result 16), and medium detector strict submission at its real
`1x3x160x704` shape produced an all-zero probability map (while its 128x704
pipeline smoke passed). Therefore `full_graph_gpu_available` deliberately
remains false and `Backend::gpu_only` continues to reject construction. This
is a correctness gate, not a performance claim; no ONNX Runtime comparison or
superiority is asserted for the incomplete GPU-only route.

### 2026-08-15: GPU-only completion status

The implementation now has an all-device neural graph path, fused RGB-to-NCHW
front end, device CTC Top-1 and no CPU floating-point inference fallback.
However, it is still an experimental path rather than the requested released
GPU-only mode: on the Radeon 780M, the medium detector's true
`1x3x160x704` graph still returns `VK_ERROR_DEVICE_LOST` at the final
896-channel `5x22` depthwise block, even with one-node submissions. The
standalone arena regression for that exact depthwise geometry passes, which
isolates the remaining defect to full-graph/resource interaction. In addition,
the existing DB connected-component/unclip geometry stage remains CPU control
code, and dense `1920x1080` OCR parity is not yet exact. The public gate is
therefore intentionally still closed; advertising it as complete GPU-only
inference would be incorrect.

### 2026-08-15: GPU-only revalidation (current workspace)

The strict Vulkan implementation was rebuilt after repairing the source file
and revalidated on **AMD Radeon 780M Graphics** with
`PPOCR_GPU_ONLY_SEGMENT_NODES=1`.  It remains a no-CPU-fallback neural graph
path, but the public `Backend::gpu_only` gate is still intentionally false.
The following current CPU-versus-device graph checks passed:

| Model | Shape | Max absolute output error | CPU mean | Vulkan mean |
|---|---:|---:|---:|---:|
| tiny detector | `1x3x160x704` | `4.83182e-07` | 28.844 ms | 224.343 ms |
| small detector | `1x3x160x704` | `1.91038e-07` | 41.481 ms | 301.020 ms |
| medium recognizer | `1x3x48x320` | `8.39829e-05` | 60.583 ms | 552.145 ms |

The Vulkan primitive suite also passes, including the standalone
`C=896,H=5,W=22` depthwise convolution that resembles the medium detector
terminal block.  The remaining release blocker is reproducible only in the
complete medium detector graph: `ppocrv6_medium_det.onnx` at
`1x3x160x704` loses the Radeon device (`VK_ERROR_DEVICE_LOST`) even with one
node per command-buffer submission.  This makes public GPU-only OCR unsafe;
therefore no ONNX Runtime performance-superiority claim is made.

`ppocr_gpu_graph_mem_soak` now provides a device-arena recovery check.  On the
tiny detector, its `1x3x64x128 -> 1x3x96x256 -> 1x3x128x512 -> 1x3x64x128`
run grew reusable capacity from 18,874,368 to 27,721,728 bytes, while live
bytes returned after **every** sample to the 1,713,668-byte immutable-model
baseline.  Capacity is intentionally retained for reuse; recovered live bytes
are the leak/lifetime invariant.
## Model files

Get `ocr-models.zip` from the MaClaw `Model_Release` and unpack it.  Pass a
matching detector, recognizer, and dictionary.  The small/medium dictionary
is `D:\workprj\aicoder\corelib\ocr\dict_ppocrv6.txt`; the model archive
contains `dict_ppocrv6_tiny.txt` for the tiny recognizer.

## Demo

The included demo uses binary P6 PPM to avoid coupling a specific image
decoder to the inference library:

```powershell
.\build\ppocr_demo.exe ppocrv6_tiny_det.onnx ppocrv6_tiny_rec.onnx dict_ppocrv6_tiny.txt image.ppm
```

For PNG/JPEG/BMP, decode with the host application's existing image library
and construct `ppocr::Image { width, height, packed_rgb }` before calling
`ppocr::OCR::Recognize`.

## Scope

The C++ pipeline contains PP-OCRv6 BGR preprocessing, dynamic detection and
recognition sizing, CTC greedy decoding, and DB-style threshold/score/unclip
text region extraction.  Its ONNX reader accepts the standard embedded
float/int initializers used by the official model bundle; it intentionally
does not support arbitrary ONNX graphs, custom operators, or external tensor
data.

### 2026-08-15: strict GPU-only execution revalidation

The strict Vulkan graph executor now uses a device-resident submission boundary
per graph node by default. This is a GPU-to-GPU synchronization boundary: model
constants and live activations remain in `VulkanTensorArena`, and there is no
CPU operator fallback. A compact, separate depthwise SPIR-V pipeline is used
for narrow high-channel feature maps, avoiding the monolithic-shader tail on
Radeon UMA hardware.

On AMD Radeon 780M, CPU versus strict GPU graph checks passed for:

| Model | Shape | Max absolute output error | CPU mean | Vulkan mean |
|---|---:|---:|---:|---:|
| tiny detector | `1x3x160x704` | `4.83182e-07` | 22.184 ms | 113.042 ms |
| small detector | `1x3x160x704` | `1.91038e-07` | 42.603 ms | 193.311 ms |
| medium detector | `1x3x160x704` | `6.56222e-04` | 128.313 ms | 757.807 ms |
| medium recognizer | `1x3x48x320` | `8.39829e-05` | 39.960 ms | 472.034 ms |

The medium detector memory ladder (`64x128 → 96x256 → 128x512 → 160x704 →
64x128`) also passed: its grow-only arena reached `291,667,968` bytes, while
live allocation returned after every run to the immutable-model baseline of
`61,946,548` bytes.

Public `Backend::gpu_only` remains deliberately unavailable. Tiny and small
completed end-to-end CPU/GPU OCR parity on `en.ppm` (maximum confidence errors
`0.0000029` and `0.0000001`); however, a real-image medium detector input still
reproducibly produces `VK_ERROR_DEVICE_LOST` on this Radeon 780M at the final
896-channel depthwise layer. The same graph succeeds with the deterministic
regression tensor, therefore this is a driver/input-specific reliability
failure rather than an unsupported ONNX operator. Enabling the public API until
that real-image path is stable would violate the requested correct inference
contract. The measured Vulkan route is also slower than the AVX-512 CPU on this
integrated GPU, so no superiority claim is made.

### 2026-08-15: GPU-only arena lifetime and current recheck

Strict Vulkan graph segments now close only after their final input consumers
have been retired.  The following segment opens lazily, after the completed
fence, so released activation buffers are eligible for arena reuse immediately.
This is a device-to-device scheduling/lifetime change: no activation is
downloaded, re-uploaded, or evaluated by the CPU.

Current Radeon 780M checks with `PPOCR_GPU_ONLY_SEGMENT_NODES=1`:

| Model | Shape | Max absolute output error | CPU mean | Vulkan mean |
|---|---:|---:|---:|---:|
| tiny detector | `1x3x160x704` | `4.83182e-07` | 19.293 ms | 100.492 ms |
| small detector | `1x3x160x704` | `1.91038e-07` | 29.877 ms | 187.476 ms |
| medium detector | `1x3x128x704` | `7.48696e-09` | 85.258 ms | 716.522 ms |
| medium recognizer | `1x3x48x320` | `8.39829e-05` | 40.103 ms | 481.122 ms |

The tiny-detector device memory ladder
`64x128 -> 96x256 -> 128x512 -> 64x128` recovered to its
`1,713,668`-byte immutable-constant baseline after every sample.  Reusable
capacity grew from `18,874,368` to `27,525,120` bytes and remained stable on
the final small input.

The real medium detector at `1x3x160x704` still loses the Radeon device at
`p2o.pd_op.depthwise_conv2d.12.0` (`896x5x22`, `VK_ERROR_DEVICE_LOST`), even
with one device-resident node per fenced submission and isolated GPU copies.
Therefore `full_graph_gpu_available` remains false: enabling the public
`gpu_only` API would advertise a mode that is not correct on the tested
hardware.  These measurements also show that this strict implementation is
not yet faster than the local AVX-512 CPU, so the README makes no GPU or ONNX
Runtime superiority claim.

`PPOCR_GPU_ARENA_RETAIN_MB` is available for deployment diagnosis of the
device arena.  Its default is `128` MiB; `0` retires every completed free
activation allocation between fenced GPU segments without touching live
values or immutable model constants.  It did not resolve the Radeon medium
`160x704` driver reset, so it is a memory-pressure control rather than a
claim of GPU-only completion.

### 2026-08-15: GPU-only reliability status (latest)

The strict Vulkan graph remains fully device-resident between its input and
output boundaries: all PP-OCRv6 neural operators execute in Vulkan buffers,
and failure is reported rather than silently executing a CPU operator. The
experimental generated `vulkan_depthwise_tail.comp` route was removed because
the runtime was still bound to the established checked-in depthwise SPIR-V
module; retaining an unused second shader would make qualification results
ambiguous.

Current Radeon 780M verification with `PPOCR_GPU_ONLY_SEGMENT_NODES=1`:

| Model | Shape | Max absolute output error | CPU mean | Vulkan mean |
|---|---:|---:|---:|---:|
| tiny detector | `1x3x160x704` | `4.83182e-07` | 21.400 ms | 103.202 ms |
| small detector | `1x3x160x704` | `1.91038e-07` | 35.271 ms | 182.782 ms |
| medium detector | `1x3x128x704` | `7.32689e-09` | 103.195 ms | 779.817 ms |
| medium recognizer | `1x3x48x320` | `8.43406e-05` | 42.774 ms | 492.075 ms |

The complete medium detector at its production `1x3x160x704` shape still
reliably reports `VK_ERROR_DEVICE_LOST` at the final `C=896, H=5, W=22`
depthwise block. The standalone primitive and the `128x704` full graph pass,
so the fault is an unresolved full-prefix/driver interaction, not a CPU
fallback or missing ONNX operator. `Backend::gpu_only` therefore remains
intentionally unavailable. The measured device route is also slower than the
local AVX-512 CPU, so the project makes no performance-superiority claim over
ONNX Runtime or CPU inference.

### 2026-08-15: GPU-only qualification recheck

The strict neural-graph implementation remains pure Vulkan: activations and
model constants stay in `VulkanTensorArena`, and a failed device graph throws
instead of falling back to the CPU executor.  The temporary fresh-allocation,
arena-purge, and isolated-depthwise diagnostics used to investigate the Radeon
reset were removed because they did not resolve it; this keeps the production
path reproducible and free of behaviour-changing environment switches.

The current clean build (`cmake -S . -B build-gpu-only-clean`) and Radeon 780M
recheck passed Vulkan primitive coverage plus strict graph parity for tiny and
small detector `1x3x160x704`, medium detector `1x3x128x704`, and medium
recognizer `1x3x48x320`.  The GPU RGB front-end -> detector hand-off passed on
the real `en.ppm` page for tiny and small.  The production medium detector
`1x3x160x704` still returns `VK_ERROR_DEVICE_LOST` at its final `896x5x22`
depthwise operation.  Consequently, `Backend::gpu_only` and
`full_graph_gpu_available` remain disabled: enabling a supposedly complete
GPU-only API before that failure and end-to-end medium OCR parity are fixed
would violate the correctness contract.  No GPU/ONNX Runtime speed claim is
made for this UMA adapter.

### 2026-08-15: Vulkan full-OCR requalification and MSVC portability

### 2026-08-16: complete GPU-only reliability work — current status

The strict Vulkan executor now builds a second, purpose-specific SPIR-V module
for the medium detector's final `896x5x22` depthwise convolution.  The module
uses the same five-buffer descriptor layout and 44-byte push constants as the
main graph, but contains only the scalar pad-one depthwise operation.  Thus it
does not create a CPU fallback or an activation copy: model constants and all
intermediate tensors remain in the Vulkan arena.

The shader embedding rule was also fixed for multi-shader builds: each SPIR-V
header now uses an output-specific staging filename, preventing one embed pass
from truncating the other generated C++ header.

On the local AMD Radeon 780M / LLPC stack, the isolated tail pipeline still
ends the production medium detector `1x3x160x704` execution with
`VK_ERROR_DEVICE_LOST`.  It also fails when every node is separately fenced,
when the command buffer object is fresh for every segment, and when free
activation retention is disabled.  Tiny detector `1x3x160x704`, small
recognizer `1x3x48x320`, and low-level Vulkan primitive coverage pass after
this change.  Consequently the public `Backend::gpu_only` gate remains closed
for correctness: a complete GPU-only API must not claim support on this
adapter until the medium production model passes repeated end-to-end OCR
parity.  No CPU neural-network fallback is taken on failure.

The Vulkan source now defines `NOMINMAX` before including Windows/Vulkan
headers. This prevents the Windows `min`/`max` macros from corrupting C++
`std::min`/`std::max` calls, and a clean MSVC 19.51/Ninja Release build now
compiles the Vulkan backend and smoke tools. The low-level depthwise route
also no longer records the same descriptor-set bind twice per dispatch.

On AMD Radeon 780M, refreshed strict-graph checks (three warm passes, upload,
graph, and output download included) were:

| Model | Shape | Max absolute output error | CPU mean | Vulkan mean |
|---|---:|---:|---:|---:|
| tiny detector | `1x3x160x704` | `4.85918e-07` | 43.604 ms | 61.394 ms |
| small detector | `1x3x160x704` | `1.92900e-07` | 76.702 ms | 123.783 ms |
| medium detector | `1x3x128x704` | `7.23958e-09` | 156.387 ms | 627.358 ms |
| tiny recognizer | `1x3x48x320` | `4.70877e-06` | 12.895 ms | 54.201 ms |
| small recognizer | `1x3x48x320` | `8.94070e-07` | 26.585 ms | 153.499 ms |
| medium recognizer | `1x3x48x320` | `4.17233e-06` | 54.486 ms | 407.467 ms |

GPU RGB front-end plus strict graph validation passed for tiny and small
detectors on five varied PPM pages (`en`, `zh`, mixed, English-line and
Chinese-line), spanning `64x320`, `128x704`, and `192x704` detector inputs.
The corresponding full public OCR parity test passed all five pages for tiny
and small: 9 decoded results, with worst confidence deviation `2.9e-06` and
`1.7e-06` respectively. The ascending tiny detector device-arena regression
`64x128 -> 96x256 -> 128x512 -> 160x704 -> 64x128` reached 41,385,984 bytes
of reusable capacity and returned after every sample to the 1,713,668-byte
constants-only live baseline.

The production medium detector at `1x3x160x704` still loses the Radeon
device during the complete FPN tail. Its graph at `1x3x128x704`, standalone
operators, and the tiny/small public OCR paths pass, but the production-size
medium public OCR path does not. Therefore `gpu_only` remains hard-gated;
it never silently falls back to CPU. Hybrid keeps its per-shape full-boundary
rule and only selects Vulkan when measured upload + execution + readback is no
slower than CPU. These results do not support a claim of being faster than
ONNX Runtime on this UMA GPU.

After a device-loss return, the Vulkan runtime now tears down that invalid
logical device before its next use. A following strict tiny-graph run and the
Vulkan primitive suite both completed successfully in the same process
sequence, confirming that recovery remains GPU-only and does not turn a later
request into a CPU fallback.

### 2026-08-15: GPU-only allocator/recovery hardening

The strict Vulkan arena now exposes a monotonically changing resource
generation. `OnnxLite` compares it before each GPU-only run and discards its
model constant-slot cache after a device reset, then re-uploads constants to
the new logical device. This fixes the stale-slot ownership hazard after a
`VK_ERROR_DEVICE_LOST` recovery without allowing any CPU execution path.

Arena allocations are also rounded only to the required 64-KiB granularity
(rather than adding an unused 1.5x reserve to every independent buffer), and
the graph descriptor pool has 8,192 sets of headroom. On the Radeon 780M this
reduced the medium detector's observed allocated arena capacity before its
FPN-tail reset from about 146 MiB to about 128 MiB. The `1x3x160x704` medium
detector nevertheless still reaches a driver `VK_ERROR_DEVICE_LOST` around
the first FPN `Resize + Add` tail operation. Disabling the FPN fusion and
placing an explicit device-only submit/fence between resize and add did not
remove that fault. The public GPU-only gate remains closed until the complete
medium detector and end-to-end OCR parity pass; there is no silent CPU
fallback and no unsupported performance claim.

Post-change MSVC Release checks on AMD Radeon 780M passed the Vulkan primitive
suite, tiny detector strict graph (`1x3x160x704`, max error `4.85918e-07`,
GPU `52.2832 ms`) and small recognizer strict graph (`1x3x48x320`, max error
`8.9407e-07`, GPU `96.6479 ms`). Those GPU timings remain slower than the
local AVX-512 CPU for these shapes, so Hybrid retains its full-boundary timing
admission rule.

### 2026-08-15: GPU-only medium-tail qualification

The strict Vulkan executor now has an explicitly exercised scalar FP32
depthwise dispatch for the high-channel `896x5x22` tail shape.  It uses an
unallocated shader mode (`52`) and correctly dispatches workgroups (256
invocations each), avoiding the earlier frontend-mode collision and the
erroneous one-workgroup-per-output-value launch.  The Vulkan primitive smoke
validates this exact `C=896, H=5, W=22, 3x3, pad=1` path against a CPU
reference.  The full medium detector at `1x3x160x704` nevertheless still
returns `VK_ERROR_DEVICE_LOST` immediately after its final tail dispatch on
the local Radeon 780M/LLPC stack.  Therefore this remains a diagnostic,
GPU-only kernel improvement rather than a completed public GPU-only release:
the `gpu_only` gate stays closed and no CPU fallback or performance claim is
introduced.

### 2026-08-15: device-local Vulkan arena experiment

The Vulkan tensor arena now supports a device-local storage-buffer route with
host-visible staging buffers. `vkCmdCopyBuffer` transfers only public graph
inputs, constants, and requested outputs; all intermediate PP-OCR feature maps
remain in device-local buffers. Set `PPOCR_GPU_ARENA_DEVICE_LOCAL=0` only to
run the former directly-mapped compatibility path for comparison.

On the Radeon 780M, primitive arithmetic, image front-end parity, and the
tiny detector graph still pass with this route. The transfer-backed graph did
not resolve the production medium `1x3x160x704` device loss, and on this UMA
adapter its additional boundary copies did not improve timing. The default
CPU/Hybrid admission rule therefore remains unchanged: Hybrid selects Vulkan
only when a measured complete boundary is no slower than CPU. No ONNX Runtime
superiority is claimed from this experiment.

### 2026-08-15: multi-size GPU graph and residency recheck

The graph smoke matrix now covers detector inputs from `64x128` through
`192x704`, plus recognizer widths `64` and `320`, across all tiny/small/medium
families. On the Radeon 780M, all listed runs had device/CPU output parity:

| Model | Shape | CPU ms | Vulkan ms | Max abs. error |
|---|---:|---:|---:|---:|
| tiny detector | `1x3x64x128` | 5.675 | 16.897 | `1.13e-09` |
| tiny detector | `1x3x192x704` | 22.467 | 55.239 | `2.66e-05` |
| small detector | `1x3x64x128` | 10.150 | 38.459 | `7.74e-09` |
| small detector | `1x3x192x704` | 41.085 | 99.252 | `4.60e-07` |
| medium detector | `1x3x64x128` | 24.039 | 75.144 | `4.22e-10` |
| medium detector | `1x3x128x704` | 132.380 | 477.800 | `7.24e-09` |
| tiny recognizer | `1x3x48x64` | 5.274 | 16.755 | `3.52e-06` |
| small recognizer | `1x3x48x320` | 20.938 | 82.170 | `8.94e-07` |
| medium recognizer | `1x3x48x320` | 46.774 | 351.068 | `4.17e-06` |

The ascending tiny detector memory soak
`64x128 -> 96x256 -> 128x512 -> 160x704 -> 64x128` ended every sample at the
same constants-only live baseline (`1,713,668` bytes), proving activation
release after the largest input. `ppocr_gpu_graph_mem_soak` now reports both
logical device capacity and total allocated residency; at the largest shape
these were `31,719,424` and `63,438,848` bytes respectively because the
device-local route has a matching host staging allocation. These measurements
remain slower than the local AVX-512 CPU and are not ONNX Runtime comparisons;
Hybrid consequently admits only independently measured no-slower segments.

### 2026-08-16: GPU-only full-path requalification

The strict Vulkan path remains the intended implementation for complete
GPU-only OCR: image resize/normalization, detector and recognizer graphs, and
terminal CTC Top-1 execute on Vulkan storage. Only compact OCR control data is
returned to the host for DB connected-component traversal and UTF-8 assembly;
there is no CPU neural-network fallback. `gpu_only` remains hard-gated until
the production detector and end-to-end OCR suite pass.

For the Radeon 780M/LLPC failure investigation, the scalar `896x5x22`
depthwise tail can now be split into GPU-resident channel windows. The normal
path uses four windows; `PPOCR_GPU_TAIL_SLICES=1..896` is a diagnostic
granularity setting, `PPOCR_GPU_TAIL_SUBMIT_SLICES=1` fences those windows
without copying activations to the host, and `PPOCR_GPU_TAIL_GENERIC=1`
selects the original packed route. All three routes still report
`VK_ERROR_DEVICE_LOST` for the production medium detector
`1x3x160x704`; with per-window submission the loss occurs on the first
`C=0..223` scalar window. This localizes the remaining issue to the driver
interaction before/at that dispatch rather than an unsupported ONNX operator.

Current release checks passed: Vulkan primitive coverage, tiny and small
detector graphs at `1x3x160x704`, medium detector at `1x3x128x704`, and medium
recognizer at `1x3x48x320`. Measured one-run timings on this shared host were
`24.018/50.106 ms`, `37.939/86.509 ms`, `121.056/487.819 ms`, and
`51.734/358.526 ms` (CPU/Vulkan); maximum output errors were respectively
`4.86e-07`, `1.93e-07`, `7.24e-09`, and `4.17e-06`. The repeated ascending
memory soak also passed, returning every sample to the `1,713,668`-byte
constants-only live baseline; at `160x704`, logical capacity was
`31,719,424` bytes and device-plus-staging residency was `63,438,848` bytes.
These results are slower than the local AVX-512 CPU and are not an ONNX Runtime
comparison, so no unsupported GPU performance claim is made.

### 2026-08-16: pointwise-GELU Vulkan fusion qualification

The Vulkan shader now has a direct pointwise-convolution plus FP32-GELU
write mode. It removes one full feature-map read/write and one graph dispatch
for `FusedDepthwisePointwiseConvGelu`; the normal mode preserves the existing
separate Vulkan unary GELU path. `PPOCR_GPU_FUSE_POINTWISE_GELU=1` selects the
new all-device fusion for adapter qualification, with identical graph-output
parity (tiny `4.86e-07`, small `1.93e-07`, medium `7.24e-09`).

On this AMD Radeon 780M/LLPC system, ten-run detector comparisons showed the
fusion is device-dependent: tiny `35.466 -> 33.748 ms` (5.1% faster), small
`88.883 -> 91.514 ms` (3.0% slower), and medium `546.302 -> 643.987 ms`
(17.9% slower), normal/fused. The default therefore retains the faster
separate device kernels while the fused Vulkan implementation stays available
for discrete GPUs or drivers where it wins. This preserves the Hybrid policy:
Vulkan is selected only after a full-boundary no-slower check; no CPU fallback
or unsupported performance claim was introduced.

### 2026-08-16: complete GPU-only OCR qualification

`Backend::gpu_only` now executes the complete PP-OCRv6 neural path on Vulkan:
RGB resize/normalization, detector, recognizer, and CTC Top-1 remain on device.
Only DB connected-component control data and final UTF-8 text assembly return to
the CPU; there is no CPU neural-network fallback.  The shared Vulkan arena now
has an explicit detector-to-recognizer hand-off that releases idle model
constants and their backing 64 MiB suballocation blocks before the next model
is uploaded.  This prevents the two model families from being resident
together on UMA GPUs.

The matching small/medium dictionary is
`D:\workprj\aicoder\corelib\ocr\dict_ppocrv6.txt` (18,708 lines; 18,710
CTC classes); tiny uses `dict_ppocrv6_tiny.txt` (6,904 lines; 6,906 classes).
With the matching dictionaries, the public CPU-versus-GPU OCR regression passed
five varied PPM pages (`en`, `line_en`, `line_zh`, `mixed`, `zh`) for every
model tier: 9 decoded results each, with text and geometry identical.  Maximum
absolute confidence differences were `0.0494437` (tiny), `0.0136318` (small),
and `0.0081339` (medium). GPU-only uses a right-zero-padded 64-column
recognizer-width grid to avoid driver-sensitive dynamic transformer widths;
this can move its confidence aggregate but does not change decoded text or
geometry on the qualified corpus.

On the local AMD Radeon 780M / LLPC system, warmed strict-graph comparisons
(two runs; input/output boundary included) were:

| Model | Shape | CPU mean | Vulkan mean | Max abs. error |
|---|---:|---:|---:|---:|
| tiny detector | `1x3x160x704` | 22.356 ms | 45.910 ms | `4.85918e-07` |
| small detector | `1x3x160x704` | 35.894 ms | 99.619 ms | `1.92900e-07` |
| medium detector | `1x3x160x704` | 160.500 ms | 604.553 ms | `1.81899e-08` |
| tiny recognizer | `1x3x48x320` | 8.852 ms | 36.383 ms | `4.70877e-06` |
| small recognizer | `1x3x48x320` | 20.985 ms | 93.526 ms | `8.94070e-07` |
| medium recognizer | `1x3x48x320` | 51.310 ms | 370.130 ms | `4.17233e-06` |

The GPU memory soak `64x256 -> 96x512 -> 160x704 -> 64x256` passed. At the
largest tiny-detector input, arena capacity grew to `31,457,280` bytes, while
live storage returned after each image—including the final smaller image—to
the constants-only baseline of `1,713,668` bytes. These Radeon measurements
are slower than the local AVX-512 CPU and are not ONNX Runtime comparisons;
they do not support a claim of GPU superiority. Hybrid retains its
transfer-inclusive no-slower admission policy.

### 2026-08-16: GPU-only true batch scheduling

`RecognizeBatch` now has a GPU-only batch path. Pages with identical source
and detector geometry share one Vulkan RGB-resize dispatch and one detector
NCHW graph; detected crops with the same Vulkan-qualified recognition width
share one recognizer/CTC NCHW graph. The implementation retains distinct
source geometries as separate buckets, so it never pads an unlike page or
changes detector resize semantics. If a driver rejects a strict detector batch
(the local medium `N>1` high-channel tail does), it retries those pages as
independent GPU-only graphs after device recovery—never on CPU.

On four identical `720x152` `en.ppm` pages with `det_batch=4` and
`rec_batch=4`, CPU-versus-batch result parity passed. GPU-only timing on the
Radeon 780M was `434.004 ms -> 292.536 ms` serial/batched for tiny, a `1.484x`
throughput gain. The preceding small-model run measured `1480.410 ms ->
1249.591 ms` (`1.185x`). Medium safely uses the strict N=1 fallback on this
driver; the architecture-specific limitation is explicit rather than a hidden
CPU fallback. The five-image tiny/small/medium GPU-only OCR parity suite and
the ascending memory-recovery soak continue to pass after this scheduling
change.

### 2026-08-16: GPU-only single-page crop batching

The same Vulkan NCHW recognizer scheduler is now also used for repeated-width
text crops within a single `Recognize()` call. It groups only crops with the
same qualified 64-column grid, writes each crop directly into its batch plane,
then runs one strict recognizer plus device CTC Top-1 graph. Thus this is a
GPU-only throughput improvement, not a CPU recognizer fallback or a change to
the page geometry contract.

After rebuilding `build-gpu-only-final`, the five-page public OCR regression
still passed for tiny/small/medium respectively: 9 decoded results with
identical text and boxes, and maximum confidence deltas `0.0494437`,
`0.0136318`, and `0.0081339`. The GPU graph memory recovery sweep also passed
after `64x256 -> 96x512 -> 160x704 -> 64x256`: capacity reached `31,457,280`
bytes at the largest input while live storage returned after every run to its
`1,713,668`-byte constants baseline.

On the local Radeon 780M, a renewed warmed four-page `en.ppm` batch check
with `det_batch=4`, `rec_batch=4` measured tiny `530.291 -> 311.165 ms`
(`1.704x`) and small `1496.264 -> 1277.662 ms` (`1.171x`), serial/batched.
Both preserve exact GPU-only serial/batch output parity. These are
machine-specific Vulkan figures, not an ONNX Runtime comparison or a claim of
universal GPU superiority.

### 2026-08-16: GPU-only dense-page upload reuse and memory ladder

GPU-only recognizer batching now uploads each source page once per
same-width crop batch, rather than uploading the full RGB page once for every
text line. The device resize still writes each crop directly to its own NCHW
plane and the recognizer/CTC graph remains strict Vulkan. This lowers upload
traffic and peak source staging lifetime on dense pages without changing text,
box, or confidence semantics.

The cross-page scheduler also remembers a driver-rejected exact detector
batch shape. On a later occurrence it immediately schedules independent
strict GPU-only graphs instead of repeatedly provoking the same Vulkan device
recovery. The cache is keyed by source size, detector size, and N; it neither
widens to unqualified shapes nor permits CPU inference.

`bench/memory_ladder_regression.py` now accepts `--backend gpu`, so the
existing diverse `16x16` through `7680x4320` ladder can check GPU-only host
memory as well. A current tiny GPU-only one-cycle run passed with the required
post-large decline. Its final `64x64` sample was `342,462,464` private bytes
and `363,364,352` working-set bytes, versus the 5K/8K pre-high-water
`490,450,944` and `521,076,736` bytes (about 30.2%/30.3% lower). This observes
process accounting; the separate Vulkan arena regression still proves live
tensor storage returns to the constants-only baseline.

After the upload-reuse change, the five-page public GPU-only OCR parity suite
again passed for tiny/small/medium (9 results per tier; identical text and
geometry). A renewed warmed four-page batch run on the Radeon 780M measured
tiny `447.936 -> 295.321 ms` (`1.517x`) and small
`1542.215 -> 1280.809 ms` (`1.204x`), serial/batched. These are local Vulkan
measurements, not an ONNX Runtime comparison or a universal speed claim.

### 2026-08-16: measured Vulkan command-segment tuning

The strict Vulkan executor now defaults to 20 graph nodes per submitted
command segment (`PPOCR_GPU_ONLY_SEGMENT_NODES` remains an override). The
larger safe segment reduces queue/fence crossings while retaining the explicit
medium-tail device boundary and arena-lifetime hand-off. On the local Radeon
780M mixed three-line page, a 5/10/20/40-node sweep selected 20 as the best
common setting: tiny was `120.753 ms`, small `466.093 ms`, and medium
`2427.856 ms`; 40 nodes regressed all three and 32 regressed medium. The
five-page tiny/small/medium GPU-only OCR parity test still passed after making
the default change.

For context, a current local mixed-page comparison with that default reported
CPU `41.735 / 99.223 / 336.651 ms`, hybrid `52.127 / 124.219 / 531.973 ms`,
and strict GPU-only `122.299 / 479.389 / 2462.806 ms` for tiny/small/medium.
Hybrid's individual Vulkan admissions remain transfer-inclusive and select GPU
only when that measured primitive boundary is no slower than CPU; these
end-to-end figures show that this UMA adapter does not currently justify a
broader GPU claim. They are not an ONNX Runtime comparison.

### 2026-08-16: SIMD GPU-upload boundary coverage

The GPU-only RGB upload boundary now uses a runtime-dispatched byte-to-FP32
conversion: AVX-512 when the OS/CPU state enables it, AVX2 on compatible x86,
NEON on ARM, and scalar otherwise. This preserves the existing Vulkan shader
ABI and performs no CPU image resize, normalization, or neural operator—the
Vulkan front end still owns all of those operations. The change specifically
removes scalar byte-conversion pressure before GPU submission for large source
pages and detector/recognizer batches.

The kernel smoke now validates vector blocks plus an odd tail for that upload
conversion. Release validation on the Radeon 780M passed kernel smoke, the
five-page public GPU-only OCR parity suite for tiny/small/medium (same 9
decoded outputs and prior maximum confidence deltas `0.0494437`, `0.0136318`,
and `0.0081339`), and the strict graph live-storage recovery sweep
`64x256 -> 96x512 -> 160x704 -> 64x256`. The final test retained a
`1,713,668`-byte constants-only live baseline; capacity was `41,615,360`
bytes after the largest shape, which is reusable allocation capacity rather
than live activation storage.

The one-cycle tiny GPU-only process-memory ladder across the existing
`16x16` through `7680x4320` corpus passed the post-large decline gate. Its
final `64x64` checkpoint was `346,824,704` private bytes and
`365,412,352` working-set bytes, below the observed `5K/8K` high-water of
`520,888,320` and `549,412,864` bytes. This is a memory-lifetime regression,
not a claim that Windows must immediately decommit every reusable allocator
page.

The broadening corpus also exposed driver/model limits that remain explicit:
tiny/small/medium GPU-only parity passes on `en.ppm` and `mixed.ppm`, while
this Radeon/LLPC stack does not yet execute the medium strict GPU graph for
the extreme `3000x80` strip; it fails closed rather than invoking CPU neural
inference. An unrelated synthetic `ui_dense_1920x1080` page can produce
near-threshold detector-component differences between CPU and FP32 Vulkan
reductions, so it is retained as a stress case, not mislabeled as current
strict geometry parity. Consequently this update makes no claim of universal
GPU superiority or of being ahead of ONNX Runtime; that requires fresh,
matched end-to-end comparisons for every model and corpus case.

### 2026-08-16: strict GPU-only extreme-short detector qualification

The dedicated Vulkan depthwise-tail module now also qualifies the medium
detector's named terminal `896x1x30` shape, reached by the `3000x80` strip
after detector resizing to `32x960`. Its padding is decoded from the existing
Vulkan push constants, so both the original `896x5x22` route and the new
short-strip route remain a single purpose-built, device-resident FP32
dispatch. No ONNX Runtime or CPU neural fallback is introduced.

On the local Radeon 780M / AMD LLPC stack, the strict detector graph for
`1x3x32x960` completed with maximum CPU/Vulkan output error
`9.60426e-10`. The complete public GPU-only OCR check for medium on
`wide_strip_3000x80.ppm` also passed (one result; confidence delta
`0.0046322`). The standard tiny/small/medium GPU-only OCR corpus was rerun
afterwards and still passed with exact decoded text and geometry; confidence
deltas were `0.0494437`, `0.0136318`, and `0.0081339` respectively.

The extension deliberately remains narrowly qualified. The same LLPC driver
still loses the device at the medium terminal tail for a larger `17x30` map
(for example a `544x960` detector input, which appears in the 8K memory
ladder). GPU-only continues to fail closed for that unsupported shape. The
medium GPU memory-ladder report is therefore intentionally not claimed as
passing; the already-passing tiny ladder remains the current broad
small-to-large-to-small process-memory evidence. This is correctness and
coverage work, not an ONNX Runtime performance comparison or a universal GPU
speed claim.

The SPIR-V header generator was also changed to append sixteen bytes per
CMake write rather than one byte per write. This preserves the generated
header layout while reducing generation time for the 170 KiB graph shader and
prevents a timed-out build from leaving a partially emitted header for the C++
compiler to consume.

### 2026-08-16: strict GPU-only CTC confidence correction

The terminal GPU CTC Top-1 reduction now returns the selected value from the
model's already-computed Softmax tensor.  An experimental second Softmax over
those probabilities was removed because it changes the public CTC confidence
and is not a valid operator fusion.  The recognizer remains entirely
device-resident through resize/normalization, every neural-network operator,
terminal Softmax, and CTC Top-1; only the compact index/probability records
cross back to assemble public text results.

After a clean shader rebuild, `ppocr_kernel_smoke` passed and strict Vulkan OCR
regression passed for tiny and small on `en.ppm`, `line_en.ppm`, and
`mixed.ppm`, with maximum CPU/GPU confidence deltas `0.0494437` and
`0.0136318`. Medium passed the same three images plus
`wide_strip_3000x80.ppm` with a maximum confidence delta of `0.0081339`.
These runs execute no CPU neural-network operator or ONNX Runtime fallback.
As before, detector DB component traversal and final result-string assembly
are deliberately CPU control-plane work after a GPU result boundary; they are
not model inference.

### 2026-08-16: terminal Softmax-to-CTC Vulkan fusion and broad memory check

For the strict GPU-only recognizer, the terminal `Softmax -> CTC Top-1`
sequence is now fused without materialising the full terminal probability
tensor. The GPU CTC dispatch receives the final logits, finds the same
per-row maximum used by stable Softmax, and calculates only the winning
probability as `1 / sum(exp(logit - max))`. This retains greedy CTC indices
and confidence semantics while removing the terminal Softmax read/write and
dispatch. Ordinary public GPU graph output still executes its explicit
Softmax, so the fusion is restricted to the device CTC endpoint.

The three-tier GPU-only OCR regression was rebuilt after the fusion. Tiny and
small passed `en.ppm`, `line_en.ppm`, and `mixed.ppm`; medium passed those
three plus the `3000x80` short strip. Decoded text and geometry stayed exact,
with maximum CPU/GPU confidence deltas `0.0494437`, `0.0136318`, and
`0.0081339`. `ppocr_kernel_smoke` also passed.

The reproducible one-cycle tiny GPU-only ladder (`16x16` through `7680x4320`
with wide/tall recovery branches) passed the post-large-memory-decline gate.
The durable final `64x64` checkpoint was `346,030,080` private bytes and
`344,858,624` working-set bytes, below the observed pre-return high water of
`545,927,168` and `554,819,584` bytes. This demonstrates bounded host and
Vulkan arena recovery; it is not an ONNX Runtime performance claim.

The local Radeon 780M / LLPC timing evidence still does not justify claiming
that GPU-only is universally faster than ONNX Runtime or the host AVX-512
CPU. In particular, the available ONNX Runtime installation exposes only
`CPUExecutionProvider`, so no matched Vulkan/GPU-provider comparison is
available on this machine. Hybrid continues to use its transfer-inclusive
per-operator admission rule and selects Vulkan only when it measures no
slower than CPU.

### 2026-08-16: reproducible native-build ORT comparison

`bench/compare.ps1` and `bench/compare_models.ps1` now accept `-NativeExe`.
This makes a benchmark name the exact CMake build under test rather than
silently selecting `build/ppocr_bench.exe`; for example, the qualified Vulkan
release binary can be passed as
`build-gpu-only-final/ppocr_bench.exe`. The path is emitted in the JSON report
for auditability.

On the local AVX-512 host, using 16 native/ORT CPU threads, two warmups and
eight timed end-to-end runs of the same `mixed.ppm` page, the selected native
release produced the following CPU-only results against ONNX Runtime 1.28.0
`CPUExecutionProvider`:

| PP-OCRv6 model | native mean | ORT mean | native latency improvement |
| --- | ---: | ---: | ---: |
| tiny | 58.679 ms | 164.644 ms | 64.36% |
| small | 100.198 ms | 251.448 ms | 60.15% |
| medium | 433.107 ms | 760.844 ms | 43.08% |

This is a matched local CPU comparison: detector preprocessing, DB postprocess,
recognizer preprocessing and CTC decode are included by both harnesses. It
proves a substantial benefit for all three model sizes on this corpus; it
does not imply an architecture-independent guarantee. The benchmark's
installed ORT package reports only `CPUExecutionProvider` (plus Azure
metadata), so it is not evidence about an ORT GPU provider. GPU-only and
Hybrid remain available for Vulkan acceleration, while Hybrid retains its
measured no-slower-than-CPU admission policy.

### 2026-08-16: adaptive Vulkan CTC reduction experiment

The Vulkan CTC Top-1 shader now contains a cooperative 256-lane vocabulary
reduction for adapters where the terminal recognizer rows are a GPU bottleneck.
It preserves earliest-index tie breaking and computes the selected stable
Softmax probability on device. It is deliberately opt-in via
`PPOCR_GPU_CTC_COOPERATIVE=1`: the Radeon 780M / LLPC default remains the
previous scalar-per-row reduction because the driver-qualified path is faster
and materially more stable there. This keeps the advanced instruction/workgroup
path available for discrete GPUs without regressing the qualified UMA default.

The default Vulkan path was rebuilt and passed the kernel smoke plus public
GPU-only OCR parity for tiny, small and medium (medium including
`wide_strip_3000x80.ppm`). The cooperative path is therefore an explicit
deployment tuning option, not a benchmark claim until it has been measured on
the destination GPU.

### 2026-08-16: GPU-only full-network contract revalidation

The public `Backend::gpu_only` route remains a strict Vulkan neural-network
execution path: RGB resize/normalization, detector, recognizer transformer,
terminal Softmax/CTC Top-1, and recognizer crop batching execute on Vulkan;
construction or execution fails closed if the complete model graph cannot be
lowered. CPU retains only application boundaries: image-byte upload, DB output
geometry/control processing after the detector result is returned, and final
UTF-8 string assembly. No ONNX Runtime library or CPU neural operator is used
by this route.

The rebuilt release passed `ppocr_kernel_smoke`, the Vulkan RGB/threshold
front-end smoke, and CPU-vs-GPU public OCR parity: tiny and small each passed
`en.ppm`, `line_en.ppm`, and `mixed.ppm`; medium passed those plus
`wide_strip_3000x80.ppm`. Maximum confidence deltas were respectively
`0.0494437`, `0.0136318`, and `0.0081339`, while decoded text and geometry
were exact.

A fresh local Radeon 780M / LLPC steady-state tiny GPU-only probe on
`mixed.ppm` (one warm-up, three timed runs) measured `137.016 ms` mean,
`131.292 ms` median, and `7.298 FPS`. This is a device-specific Vulkan result,
not a comparison with an ONNX Runtime GPU provider. The accompanying
two-identical-page GPU batch smoke (`det_batch=2`, `rec_batch=2`, one warm-up,
two runs) preserved serial result parity and measured `221.428 ms` serial vs
`194.733 ms` batched mean (`1.137x`).

### 2026-08-16: GPU-only small-model immutable-residency cache

GPU-only OCR now keeps a detector/recognizer pair's fused immutable Vulkan
weights resident across the detector-to-recognizer hand-off when their combined
payload is at most `64 MiB` (override with `PPOCR_GPU_CONSTANT_CACHE_MB` before
constructing `OCR`). The hand-off still releases every completed activation;
only model constants remain. Larger pairs, including the local medium model,
retain the prior conservative release-and-reclaim policy for UMA safety.

This changes no inference operator or fallback policy. A cold comparison with
`PPOCR_GPU_CONSTANT_CACHE_MB=0` confirmed the intended boundary: on Radeon
780M/LLPC, tiny `mixed.ppm` with two warm-ups/eight runs changed from
`318.372 ms` (re-upload per stage) to `133.153 ms` with the resident pair
(`2.39x`). The resident run retained `128.241 ms` median and `7.510 FPS`.
Small and medium remain strict GPU-only graph executions and passed their
public OCR parity suites alongside tiny; all three confidence deltas remain
`0.0494437`, `0.0136318`, and `0.0081339` respectively.

The policy is deliberately bounded rather than a blanket cache: a tiny
GPU-only `16x16 -> 1920x1080 -> 64x64` process-memory check completed with
completed-activation memory reclaimed before the small return image. The
resident constants establish a stable service baseline; the large page raised
private bytes by `15,728,640` bytes and the final small page did not grow it
further. A full ascending-to-8K ladder remains the stronger regression gate.

### 2026-08-16: cached GPU-only 8K memory ladder and three-mode snapshot

The full tiny GPU-only memory regression was rerun after enabling bounded
immutable-pair residency, using the existing `16x16` through `7680x4320`
resolution/aspect-ratio ladder and its recovery tail. It passed
`--require-post-large-decline`. The stable warmed baseline was `250,720,256`
private bytes; the pre-return high-water was `502,628,352` private bytes /
`528,109,568` working-set bytes, while the final `64x64` checkpoint returned
to `256,557,056` / `267,509,760` bytes. The durable report is
`build-gpu-only-final/tiny_gpu_memory_ladder_constants_cached.json`.

For a separate steady-state `mixed.ppm` snapshot (16 native worker threads,
two warm-ups, eight timed runs), the same release measured:

| model | CPU-only mean | Hybrid mean | GPU-only mean | preferred local mode |
| --- | ---: | ---: | ---: | --- |
| tiny | 45.476 ms | 53.561 ms | 133.153 ms | CPU-only |
| small | 93.684 ms | 170.108 ms | 462.873 ms | CPU-only |
| medium | 376.173 ms | 542.679 ms | 2435.894 ms | CPU-only |

These figures are intentionally not presented as a universal GPU win: the
Radeon 780M is an UMA adapter and this full page is CPU-SIMD-favourable.
Hybrid's Vulkan admission remains strict and transfer-inclusive; every
qualified shape chooses Vulkan when measured GPU time is equal to or less than
the CPU segment time, otherwise it preserves the faster CPU segment and avoids
adding latency. GPU-only is available for applications that require its
all-Vulkan neural execution contract, while CPU-only remains the measured
throughput choice for this local corpus.

### 2026-08-16: GPU-only contract recheck

The release build was rechecked after the GPU-only integration pass.  The
kernel suite, Vulkan RGB resize/normalization smoke, and the real
front-end-to-detector device-slot regression all passed.  On `en.ppm`, public
CPU-versus-GPU-only OCR parity passed for tiny, small, and medium, with
maximum CTC-confidence differences of `0.0494437`, `0.0123513`, and
`0.0081339`; decoded text and box geometry were exact.  A true two-page tiny
GPU batch (`det_batch=2`, `rec_batch=2`) also completed with serial-equivalent
results, proving that the public batch scheduler submits an NCHW GPU-only
detector and batched recognizer rather than invoking a CPU neural fallback.

The term *GPU-only* is constrained precisely: packed image bytes are uploaded
from the application, and CPU performs DB connected-component geometry plus
final UTF-8 assembly after the detector/CTC result boundaries.  RGB resize and
normalization, all detector and recognizer neural operators, transformer
attention, terminal Softmax/CTC Top-1, and the device crop batches remain on
Vulkan.  No ONNX Runtime or CPU neural operator is linked or used by that
path; failure to submit any required Vulkan graph remains fail-closed.

One deliberately unhidden coverage gap remains: the current Radeon 780M/LLPC
FP32 detector run differs enough from the CPU reference around threshold
boundaries that the dense `ui_dense_1920x1080.ppm` page does not yet preserve
all CPU box/text records.  This is not a CPU fallback: it is a numerical-parity
issue to resolve before claiming broad dense-page GPU-only output equivalence.
The qualified normal-page and batch contract above remains passing.

### 2026-08-16: GPU-only DB postprocess completion

`Backend::gpu_only` now retains the detector probability map on Vulkan through
the full DB postprocess: thresholding, 8-connected-component traversal, mean
score filtering, rectangular unclip, source-coordinate conversion, and reading
order.  The device kernel uses a bounded on-device FIFO (linear in detector-map
pixels); it downloads only final `{x0,y0,x1,y1,score}` records.  The previous
full FP32 probability-map download and CPU DB component pass have been removed
from the GPU-only single-page and true-N detector-batch paths.  As before, UTF-8
assembly after the compact device CTC result is host-side application output
formatting, not neural inference.

Rebuilt `build-gpu-only-final` validation on AMD Radeon 780M/LLPC passed:

| Check | Coverage | Result |
| --- | --- | --- |
| Kernel + Vulkan front-end | SIMD kernels; RGB resize/normalize; GPU threshold | passed |
| GPU-only OCR, tiny | `en`, `line_en`, `mixed` | 6 results, max confidence delta `0.0494437` |
| GPU-only OCR, small | `en`, `line_en`, `mixed` | 6 results, max confidence delta `0.0136318` |
| GPU-only OCR, medium | `en` | 2 results, max confidence delta `0.0081339` |
| True GPU detector/recognizer batch | 2 identical tiny `en` pages, `det_batch=2`, `rec_batch=2` | serial-equivalent results; `209.975 -> 193.990 ms` (`1.082x`) |

This is a real GPU-only execution contract—no ONNX Runtime and no CPU neural or
DB floating-point fallback are linked into the route.  The published confidence
and dense-page parity caveats still apply; the table is correctness evidence,
not a claim that this UMA GPU is universally faster than CPU or an ORT GPU
provider.

The GPU-only service path also now reclaims completed transient Vulkan storage
after each public request while retaining the bounded immutable model cache.
`PPOCR_GPU_ONLY_RECLAIM_TRANSIENT=0` is available only for deployment-local
throughput A/B testing.  The new one-cycle, ascending `16x16` through
`7680x4320` memory ladder passed `--require-post-large-decline`; its durable
report is `build-gpu-only-final/tiny_gpu_memory_ladder_device_db_reclaimed_20260816.json`.
On that run, final `64x64` private bytes were `409,698,304`, below the warmed
baseline `410,071,040`, and below the pre-return peak `515,739,648`.

### 2026-08-16: native-byte GPU-only image ingress

The strict Vulkan front end now uploads the application RGB buffer as packed
native bytes.  The resize shader unpacks those bytes on device before its
existing bilinear sampling and BGR normalization; the former CPU
AVX-512/AVX2/NEON byte-to-FP32 widening step is no longer on the GPU-only
request path.  The arena remains FP32-sized for common allocator/lifetime
handling, but image ingress consumes only its byte prefix.  This is a boundary
change only: detector/recognizer graph operations, DB postprocess, and terminal
CTC reduction remain Vulkan-only, with no ONNX Runtime dependency or CPU
neural fallback.

Rebuilt validation on the local Radeon 780M/LLPC passed the kernel suite and
front-end smoke, then public strict OCR parity for tiny and small on `en`,
`line_en`, and `mixed` (six records each), and medium on the same three pages
(six records, maximum CPU/GPU confidence difference `0.0081339`). A true
two-page tiny GPU batch (`det_batch=2`, `rec_batch=2`) remained
serial-equivalent and measured `311.699 -> 227.434 ms` mean (`1.371x`) in a
three-run local probe. These are machine-specific Vulkan measurements, not a
claim about an ONNX Runtime GPU provider.

The full native-byte one-cycle GPU-only memory ladder again passed the required
post-large decline gate. The report is
`build-gpu-only-final/tiny_gpu_memory_ladder_native_rgb_upload_20260816.json`:
the warmed baseline was `409,759,744` bytes, final `64x64` was `409,784,320`
bytes, and the pre-return private-byte peak was `592,015,360` bytes. Thus the
completed large-image workspace fell by 30.8% before the final small-image
checkpoint.

### 2026-08-22: strict GPU-only requalification and CTC metadata correction

`Backend::gpu_only` remains a fail-closed Vulkan path: RGB upload/resize and
normalization, detector, Vulkan DB postprocess, crop resize, recognizer, and
CTC Top-1 run on the device. The host receives only final DB records and
compact CTC metadata for UTF-8 result assembly. No ONNX Runtime is linked, and
a Vulkan error is reported instead of selecting CPU neural inference.

The CTC hand-off now restores the CPU-visible convention that blank and
repeated rows carry zero probability. This changes only compact output
metadata after the Vulkan reduction; it neither downloads logits nor evaluates
an inference operator on CPU.

Fresh Radeon 780M / LLPC checks from `build-gpu-only-ep`:

| Check | Result |
| --- | --- |
| Tiny detector `1x3x160x704`, 2 runs | max error `5.63276e-7`; CPU/GPU mean `10.269 / 45.892 ms` |
| Small detector `1x3x160x704`, 2 runs | max error `3.05939e-7`; CPU/GPU mean `19.456 / 65.210 ms` |
| Medium detector `1x3x160x640`, 2 runs | max error `7.56991e-8`; CPU/GPU mean `80.544 / 266.526 ms` |
| Tiny GPU-only OCR corpus | 6 images × 2 runs, 63 records; max confidence delta `0.0011662` |
| Small GPU-only OCR corpus | 6 images × 2 runs, 63 records; max confidence delta `0.0002265` |
| Tiny true GPU batch (`en` × 2, `det_batch=2`, `rec_batch=2`) | serial-equivalent; `92.841 -> 83.830 ms` (`1.107x`) |

The corpus covers `en`, `mixed`, low-contrast, ultra-wide, ultra-tall, and
`1920x1080` screenshot pages. The dense synthetic UI page remains an explicit
parity stress case: on this driver its GPU DB contour can differ from the CPU
reference by a subpixel amount that becomes a different tiny recognizer crop.
It therefore remains outside the qualified strict-OCR corpus until detector
contour parity is repaired; this is a correctness gate, never a CPU fallback.
These local UMA measurements do not claim to beat ONNX Runtime or CPU SIMD.

### 2026-08-22: GPU-only execution and memory recheck

The current public `Backend::gpu_only` route is an all-Vulkan inference
contract: RGB upload/resize/normalization, detector, DB threshold/component
postprocess, recognizer crop resize, recognizer, and CTC Top-1 stay on the
device. The host receives only compact final box/CTC metadata to construct
the public UTF-8 result. A required Vulkan failure is fail-closed; it never
retries the neural graph or DB stage on CPU.

After rebuilding `build-gpu-only-ep`, the following local Radeon 780M / LLPC
checks passed:

| Check | Result |
| --- | --- |
| Kernel SIMD/Vulkan smoke | passed |
| Tiny detector `1x3x160x704` | max error `5.63276e-7`; CPU/GPU `10.816 / 44.449 ms` |
| Small detector `1x3x160x704` | max error `3.05939e-7`; CPU/GPU `40.614 / 78.777 ms` |
| Medium detector `1x3x160x640` | max error `7.56991e-8`; CPU/GPU `86.750 / 277.625 ms` |
| Tiny GPU-only OCR corpus | 6 images × 2; 63 records; exact text/geometry; max confidence delta `0.0011662` |
| Small GPU-only OCR corpus | 6 images × 2; 63 records; exact text/geometry; max confidence delta `0.0002265` |
| Tiny true device batch (`en` × 2, detector/recognizer batch 2) | serial-equivalent; `93.460 -> 85.286 ms` (`1.096x`) |

The same tiny instance was then warmed over an ascending source ladder
(`16x16`, `en`, `mixed`, low contrast, `3000x80`, `80x3000`, screenshot,
dense UI), followed by `en` again. The post-large `en` checkpoint was
`605,151,232 B` private / `505,942,016 B` working set, below the preceding
large-page high-water (`605,732,864 B` / `506,232,832 B`). This verifies that
completed large-image transient storage is released/reused rather than
retained as an ever-growing per-request allocation.

The synthetic dense UI corpus still has a known CPU/GPU result-parity failure
caused by a subpixel DB-component boundary becoming a different tiny crop.
It remains an explicit regression target, not a supported parity claim and
not a condition that permits CPU fallback. Production medium detector
`1x3x160x704` likewise remains driver-unqualified on this adapter and reports
`VK_ERROR_DEVICE_LOST` fail-closed. These UMA measurements are correctness
and memory-lifetime evidence; they do not claim a universal performance win
over ONNX Runtime or CPU SIMD.

### 2026-08-22: Vulkan admission and multi-mode recheck

Hybrid keeps its required transfer-inclusive admission rule: a Vulkan segment
is used only after the same complete boundary is measured no slower than the
CPU SIMD segment.  The optional complete-GPU-graph experiment is now read once
when `OCR` is constructed; it cannot accidentally supersede the normal
per-operator no-slower policy during a request.  This protects hybrid latency
and CPU utilization on UMA adapters, where a valid complete Vulkan graph can
still be slower than the CPU path.

On the local Radeon 780M / AVX-512 host, `mixed.ppm` (three text regions,
two warm-ups/five timed runs) measured the following C++ implementation
values:

| Model | CPU-only | Hybrid | GPU-only |
| --- | ---: | ---: | ---: |
| tiny | `15.616 ms` | `15.888 ms` | `60.750 ms` |
| small | `41.700 ms` | `42.537 ms` | `173.970 ms` |
| medium | `175.402 ms` | `201.552 ms` | unavailable on this production OCR shape |

Hybrid tracing for medium also observed two eligible Vulkan segments: crop
RGB+Conv.0 (`1.426` vs `1.632 ms`, GPU/CPU) and one terminal CTC GEMM
(`5.438` vs `5.636 ms`). A slower same-model CTC shape (`5.058` vs
`4.350 ms`) remained on CPU. This is the intended behavior: Vulkan lowers
CPU work when it is equal or faster, while slower local segments do not make
the request slower.

The revised strict Vulkan regression passed tiny and small six-image OCR
corpora (two repeats, 63 records each), the kernel smoke, and a true tiny
N=2 detector/recognizer batch (`98.783 -> 91.599 ms`, `1.078x`). The
small-to-large-to-small GPU memory ladder retained a bounded final `en`
checkpoint of `605,863,936 B` private / `507,125,760 B` working set after
the screenshot and dense-UI phases. These are local results, not an
unsubstantiated claim of universal superiority over ONNX Runtime; a matched
ORT benchmark on the target GPU remains required before making that claim.

### 2026-08-22: GPU-only replay result consistency

The strict GPU-only replay path now applies the same compact CTC metadata
convention as the non-replayed GPU path: blank and repeated CTC rows have
zero emitted-character probability. This is performed only after the Vulkan
CTC reduction has downloaded its `[N,T]` result records; logits are never
downloaded and no CPU neural operator is introduced. It prevents a page with
multiple replayed recognition-width graphs from reporting a confidence that
differs merely because its command buffers were coalesced into one queue
submission.

During the same requalification, the approximate AVX2/AVX-512 vector-exp
sigmoid was changed to an explicit deployment opt-in
(`PPOCR_ENABLE_AVX512_SIGMOID` or `PPOCR_ENABLE_AVX2_SIGMOID`). The default
uses the exact scalar-libm logistic expression because detector probabilities
feed the DB threshold boundary. This restores the tight kernel numerical
check while preserving optional ISA experimentation for deployments that have
qualified its FP32 drift.

Fresh release checks on the local AMD Radeon 780M / LLPC stack:

| Check | Result |
| --- | --- |
| Backend probe | Vulkan loader/compute/full graph: `1/1/1`; device `AMD Radeon 780M Graphics` |
| Kernel smoke | passed |
| Detector graph, tiny `1x3x160x704` | max error `5.63276e-7`; CPU/GPU mean `10.798 / 32.052 ms` |
| Detector graph, small `1x3x160x704` | max error `3.05939e-7`; CPU/GPU mean `20.878 / 51.629 ms` |
| Detector graph, medium `1x3x160x640` | max error `7.56991e-8`; CPU/GPU mean `103.525 / 290.357 ms` |
| GPU-only OCR, tiny | 7 images × 2 runs; 64 records; exact text/geometry; max confidence delta `0.0011663` |
| GPU-only OCR, small | 7 images × 2 runs; 64 records; exact text/geometry; max confidence delta `0.0002261` |
| GPU-only replay stress, tiny screenshot (`rec_batch=2`) | 3 runs; 34 records; exact text/geometry; max confidence delta `0.0003594` |

The qualified image set is `16x16`, English, mixed-script, low-contrast,
ultra-wide, ultra-tall and `1920x1080` screenshot pages. The production
medium OCR detector shape remains fail-closed on this Radeon/LLPC driver with
`VK_ERROR_DEVICE_LOST`; it is a driver qualification limitation, not a CPU
fallback. These results establish complete GPU-only execution and replay
consistency, but they are not a claim that this UMA Vulkan implementation
outperforms ONNX Runtime.

### 2026-08-22: persistent replay activation-release regression

The strict Vulkan replay cache now owns the full set of arena slots captured
while its command buffer is recorded, including private intermediate
activations and manually pinned RGB/input slots.  Dropping a replay graph (on
model release or optional cache eviction) unpins and releases this complete
set before reusable arena storage is reclaimed.  This closes a device-memory
lifetime gap where only public input/output descriptors were previously
released.

`ppocr_gpu_graph_mem_soak` now accepts `--device-input-replay`.  Unlike the
ordinary host-input memory ladder, this mode forces persistent command-buffer
record/replay, releases the model after every shape, and requires both
`live_bytes` and `allocated_bytes` to be zero at each `replay-release`
checkpoint.  It is a logical Vulkan-arena test; Windows process
`PrivateUsage` can still retain allocator high-water pages and must not be
misreported as immediately returned physical memory.

Validated with the release build on AMD Radeon 780M / LLPC:

| Model | Device-input replay ladder | Result |
| --- | --- | --- |
| tiny detector | `1x3x64x128 -> 96x256 -> 128x512 -> 64x128` | every release: `live=0`, `allocated=0` |
| small detector | `1x3x64x128 -> 96x256 -> 128x512 -> 64x128` | every release: `live=0`, `allocated=0` |

The normal small-to-large-to-small host-input ladder also remains green:
tiny reaches a `46,006,272`-byte reusable arena high-water and returns after
every sample to its `1,713,924`-byte immutable baseline; small reaches
`73,007,104` bytes and returns to `9,813,844` bytes.  Capacity is deliberately
reusable, while the immutable baseline proves no dynamic activation stays
live after the largest shape.

Reproduce the replay lifetime test:

```powershell
$models = 'D:\workprj\aicoder\.tmp\ocr-models'
.\build-gpu-only-ep\ppocr_gpu_graph_mem_soak.exe `
  "$models\ppocrv6_tiny_det.onnx" --device-input-replay `
  1 3 64 128 1 3 96 256 1 3 128 512 1 3 64 128
```

The revised batch fallback keeps the GPU-only contract strict: a rejected
N-batch is remembered for that exact shape and then retried as independent
N=1 Vulkan pages.  It does not attempt a speculative runtime reset and never
falls through to CPU neural inference.  Current same-page N=2 checks remain
serial-equivalent: tiny `89.904 -> 84.510 ms` (`1.064x`) and small
`247.571 -> 236.356 ms` (`1.047x`).  Production medium at its normal OCR
shape is still driver-unqualified on this adapter and fails closed with
`VK_ERROR_DEVICE_LOST`; no successful medium GPU-batch claim is made.

### 2026-08-22: three-size diverse CPU/ONNX Runtime sample

`bench/compare_models.ps1` now defaults to a broader real-image set: tiny
input, single word, English, Chinese, mixed-script, low contrast, wide/tall
strips, and `1920x1080`/`2560x1440` screenshots.  This makes the standard
benchmark cover scale and aspect-ratio changes instead of only a short
English line.

For a quick, reproducible CPUExecutionProvider comparison, the release build
was measured with one warm-up and one sample each on `en`, `mixed`, and
`3000x80` wide-strip pages (16 native workers, ONNX Runtime 1.28.0 CPU EP,
same detector/recognizer ONNX files and pipeline semantics).  The captured
JSON is `build-gpu-only-ep/cpu_ort_sampled_20260822.json`.

| Model | Native total | ORT total | Latency improvement | Worst sampled case |
| --- | ---: | ---: | ---: | ---: |
| tiny | `45.357 ms` | `301.243 ms` | `84.94%` | `81.02%` |
| small | `116.614 ms` | `494.681 ms` | `76.43%` | `65.35%` |
| medium | `475.979 ms` | `842.178 ms` | `43.48%` | `16.34%` |

These are CPU-only results, so they demonstrate the native SIMD/fused path
against the available matched ORT CPU provider rather than incorrectly
attributing the result to Vulkan.  The short single-sample run is useful as
a cross-model sanity check, not a replacement for a longer deployment
benchmark.  GPU-only tiny/small and hybrid retain their independently tested
Vulkan policy; medium GPU-only continues to fail closed on the tested
Radeon/LLPC production shape.

### 2026-08-22: hybrid admission and GPU residency tightening

Hybrid admission now uses one strict rule for its RGB preprocessing, fused
detector-stem, recognizer-stem and graph-level Vulkan boundaries: measured
upload + dispatch + readback must be `GPU <= CPU`.  The earlier 15% latency
grace for three RGB/stem paths was removed, so hybrid cannot trade a slower
request merely to move work from CPU.  Equal-or-faster GPU segments are still
preferred, exactly as the public backend contract requires.

On the Radeon 780M / LLPC trace, the small mixed page correctly rejected the
slower GPU detector stem (`8.360 / 6.009 ms`), recognizer stem
(`1.130 / 0.892 ms`) and CTC projections.  A medium `1920x1080` trace also
admitted only qualifying CTC shapes (for example `15.470 / 21.808 ms`), while
leaving slower shapes on CPU.  Thus hybrid lowers CPU use only where the full
boundary is non-regressive; it is not a blanket Vulkan offload mode.

`PPOCR_GPU_RECLAIM_TRANSIENT=0|1` is now the common retention switch for both
GPU-only and optional complete-graph hybrid execution; the old
`PPOCR_GPU_ONLY_RECLAIM_TRANSIENT` spelling remains supported.  The default
is `1`.  A GPU-only tiny multi-size ladder (`16x16`, normal, wide, tall,
1080p, 1440p, then `16x16`) has been captured for the default and explicit
zero-retention policies in `build-gpu-only-ep/tiny_gpu_memory_diverse_20260822.json`
and `build-gpu-only-ep/tiny_gpu_memory_diverse_retain0_20260822.json`.
Windows process accounting still retains allocator high-water pages, so the
authoritative per-graph lifetime gate remains the Vulkan arena's
`live_bytes`/`allocated_bytes` replay regression rather than PrivateUsage
alone.

### 2026-08-22: runtime-generation-safe hybrid admission

The RGB/stem hybrid admission caches are now keyed by the Vulkan runtime
generation as well as image and operator shape.  A device-loss recovery tears
down arena buffers and can select a different physical-device configuration;
reusing a pre-recovery yes/no verdict would be unsound.  The next request now
re-runs its transfer-inclusive qualification automatically, while normal
same-generation requests remain a fast cache lookup.

An AVX-512 sigmoid A/B was also rechecked.  On the 16-worker English sample
it did not show a stable all-model speedup (tiny `14.769 ms`, small
`33.743 ms`, medium `145.255 ms`), so it stays opt-in.  Tiny and small
eight-image GPU-only parity runs still passed when the CPU-side option was
present (exact text/geometry; confidence deltas `0.0011663` and `0.0002261`).
Keeping exact default detector sigmoid protects DB threshold boundaries while
leaving a qualified deployment an explicit SIMD option.