Llama.cpp b11013: Target Vulkan validation at IM2COL buffer alignment

General
1

If your local inference service uses llama.cpp’s Vulkan backend and its workload exercises IM2COL or IM2COL_3D, b11013 warrants a targeted validation run before promotion. The reason is a specific shader alignment fix, with an upstream report of GPU-assisted validation hits falling from 20 to zero for both operators.

The b11013 release page, marked pre-release and associated with commit 05f2dcf, explains the mismatch:

  • im2col.comp and im2col_3d.comp declare D_ptr without an explicit buffer_reference_align, so glslang emits writes as Aligned 16.
  • The shaders advance that pointer by D_SIZE: 4 bytes for float, or 2 bytes for float16_t. Most write addresses consequently do not satisfy the declared 16-byte alignment.
  • Declaring buffer_reference_align = D_SIZE matches the alignment to the actual write stride.

Upstream identifies the resulting GPU-assisted validation warning as VUID-RuntimeSpirv-PhysicalStorageBuffer64-06315. That exact warning is the useful target for a reproduction check.

The reported 20 → 0 result has a narrow meaning. The release does not identify the GPU, driver, model, tensor shapes, or complete validation harness behind those counts. It also supplies no inference-speed measurement or numerical-output comparison. Treat the counts as an upstream validation result; they do not establish faster inference, universal output correctness, or benefits across other operators and backends. The linked PR #28996 and issue #28960 are references on the release page, not additional evidence assessed here.

For an API service backed by an affected local Vulkan workload, I would use the following promotion check:

  1. Establish coverage. Choose a workload that actually exercises IM2COL or IM2COL_3D, and record which operator and data-type variants it reaches. A clean run that never reaches the affected shaders cannot demonstrate this fix.
  2. Compare the builds under the same conditions. Run the current build and b11013 with GPU-assisted validation, holding the GPU, driver, model, inputs, tensor shapes, and runtime settings constant. Record the build identifiers and occurrences of the specific VUID. The release does not provide a complete reproduction command, so this needs an environment-specific harness.
  3. Interpret the result conservatively. If the baseline produces the warning and b11013 clears it on the same exercised path, that supports resolving this alignment issue in that environment. If the baseline is already clean, record that the upstream failure was not reproduced locally; do not present the run as a confirmed before/after fix.
  4. Keep output and latency checks separate. Use representative requests and your existing acceptance criteria before promoting the build. Clearing this validation warning does not answer those service-level questions.

These are recommended checks, not results from a test performed here. If your workload’s operator coverage is unknown, establish that first: it determines whether this release note gives you a concrete validation priority.

2

I would make the production handoff carry two separate verdicts: shader validation and deliverable acceptance. For b11013, “the alignment warning cleared” should not become “the content pipeline is fixed.” The release note reports the IM2COL/IM2COL_3D validation change, not an assessment of finished assets.

For a content workflow that actually reaches those operators, I would turn the separate output check into a small acceptance sheet attached to the build comparison:

  • Identify the source asset, its preprocessing settings, and the downstream artifact being approved. Keep those inputs fixed across the comparison.
  • Define the artifact’s pass criteria before examining the new output. For a hypothetical captioning workflow, these might include preserving required names, avoiding unsupported details, and retaining the required output format—not matching every sentence verbatim. This is an example of an acceptance rubric, not a claim that b11013 adds captioning support.
  • Record the content reviewer’s verdict independently of the GPU-validation result. If the warning clears but the artifact fails its rubric, keep the production promotion blocked and investigate the output difference without assuming the alignment patch caused it.

That gives the person accepting the deliverable a concrete decision to sign off on, rather than asking them to interpret a clean shader log as evidence of content quality.