Amd on tsvinc

Eighteen days later, the same lie

Sun, 01 Nov 2026 00:00:00 +0000

Builds on Inventing the work vs promising what isn't there, where this model first earned its flag.

Here is a paragraph from a README that a local model, working as a coding agent on a Java money-transfer ticket, wrote on the evening of 31 October, in a batch of runs that started at 21:08:

Atomicity: All-or-nothing semantics. Either both accounts are updated or neither is. If the repository fails part-way through (e.g., connection lost on the second save), the operation is rolled back: balances are unchanged and no audit events are appended.

The template differed. The prompts didn't.

Sat, 31 Oct 2026 00:00:00 +0000

Builds on Read the transcript, not the gate, where a chat template broke every Claude Code session on four models.

The plan had one variable. Same model, two quantizations, only the weights differ, and I was about to run it on Ornith-1.5-122B, a 122-billion-parameter mixture-of-experts coding model, on my 128 GB AMD Strix Halo box. On one side, the 4-bit UD-Q4_K_XL from unsloth, a team that publishes quantized builds of many big open models, about 80 GB. On the other, a GSQ-RCO IQ3_S from the Hugging Face account fajardc, about 53 GB, a mixed quant whose tensors range from IQ2_XS to Q6_K. Ten coding-agent runs each: five tasks in five languages, each through two agent harnesses, opencode and Claude Code, the programs that turn a model's replies into file edits and shell commands.

Two rounds, seventeen arms: the engine set the speed, not the quant

Fri, 30 Oct 2026 00:00:00 +0000

Builds on Five languages, two reps: the round-two ranking, which ranks these arms by the quality of their code. This post is about how fast they got there.

Qwen3.8-Flash-Next, a mixture-of-experts model, ran at two quantizations (a quant sets how many bits each weight gets) in round two of my study of local models as coding agents, six model setups on the same coding tickets on my 128 GB AMD Strix Halo box. At Q2_0, 2.40 bits per weight, it generated 58.9 tokens per second; at IQ4_XS, 4.25 bits per weight, 26.6. A 66.4 GB file beating a 93.7 GB one by 2.2x is what a smaller quant is supposed to do: fewer bytes to read per token, more tokens per second. There should be a rule that a speed gap lists everything that changed before it is allowed an explanation. This one listed one thing.

Enable VA-API HEVC decode on Fedora with an AMD GPU

Sun, 25 Oct 2026 00:00:00 +0000

Make an AMD GPU decode HEVC (Main and Main 10) through VA-API on Fedora 44 by installing RPM Fusion's mesa-va-drivers-freeworld, after checking that the hardware decodes HEVC and Fedora's own driver doesn't offer it.

Tested on: Fedora 44 desktop (KDE Plasma 6.7, X11), AMD Radeon 780M iGPU (radeonsi, phoenix), kernel 7.2.10-200.fc44, Mesa 26.2.5-1.fc44, mesa-va-drivers-freeworld 26.2.5-1.fc44, libva 2.23.0-3.fc44 (VA-API 1.23), libdrm 2.4.134-1.fc44, ffmpeg 8.1.3-1.fc44 (RPM Fusion), mpv 0.41.0-5.fc44 (2026-10-25).
Not verified: decoding a real H.264 clip (the H.264 profiles appear in step 11, but no H.264 clip was decoded); Haruna, browsers or other players with the new driver; Intel or NVIDIA GPUs; other distributions; Vulkan video decode; Wayland; 32-bit (i686) VA-API programs, and RPM Fusion's i686 build of mesa-va-drivers-freeworld (not installed here); what dnf does when Fedora ships a newer Mesa before RPM Fusion rebuilds this package (only the version pin was observed); the rollback.
Needs: an AMD GPU on the amdgpu kernel driver with render node /dev/dri/renderD128; the RPM Fusion free repository; RPM Fusion's ffmpeg for the test clips; mpv for the player check; python3; sudo for the install. The two scripts attached to this page: amdgpu_video_caps.py and va_profiles.py.
Time: 15 min.
Risk: low. One package is added and nothing is removed (step 7). While it is installed, every 64-bit VA-API program on the host that doesn't set LIBVA_DRIVERS_PATH gets RPM Fusion's driver, which lists no JPEG decode profile. That driver file is a link to libgallium, the Mesa library that Fedora's EGL and GLX libraries and GBM's DRI backend also link, and the x86_64 package that step 8 installs puts its own copy ahead of Fedora's on the 64-bit linker path, so Fedora's 64-bit builds of those resolve to RPM Fusion's copy too; the 32-bit (i686) builds on this box keep Fedora's (Notes). The package pins the Mesa version, so each new Mesa version needs a matching rebuild from RPM Fusion. Undo: remove the package (not exercised).

Before you start#

Package versions and vendors:

$ rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' ffmpeg ffmpeg-libs mpv libva libdrm mesa-dri-drivers
ffmpeg-8.1.3-1.fc44 RPM Fusion
ffmpeg-libs-8.1.3-1.fc44 RPM Fusion
mpv-0.41.0-5.fc44 Fedora Project
libva-2.23.0-3.fc44 Fedora Project
libva-2.23.0-3.fc44 Fedora Project
libdrm-2.4.134-1.fc44 Fedora Project
libdrm-2.4.134-1.fc44 Fedora Project
mesa-dri-drivers-26.2.5-1.fc44 Fedora Project
mesa-dri-drivers-26.2.5-1.fc44 Fedora Project

Expected: ffmpeg and ffmpeg-libs from RPM Fusion. Two lines for one package are its x86_64 and i686 builds (the format string prints no arch). If ffmpeg is not installed and Fedora's ffmpeg-free is, sudo dnf swap ffmpeg-free ffmpeg --allowerasing replaces it (that is how this box got it, in July); why that matters for players is in Two libavcodecs behind one soname.

The RPM Fusion free repository is configured:
```
$ rpm -q rpmfusion-free-release
rpmfusion-free-release-44-3.noarch
```
Expected: an rpmfusion-free-release package for your Fedora release. The freeworld driver comes from rpmfusion-free-updates (step 9).
ffmpeg can encode the test clips:
```
$ rpm -q --requires ffmpeg-libs | grep -E 'libx265|libSvtAv1Enc'
libSvtAv1Enc.so.3()(64bit)
libx265.so.215()(64bit)
```
Expected: both libraries. Step 4 encodes with libx265 and libsvtav1. Fedora's ffmpeg-free was not tried for this.

The render node belongs to the amdgpu kernel driver:

$ readlink /sys/class/drm/renderD128/device/driver
../../../../bus/pci/drivers/amdgpu

Expected: a path ending in amdgpu.

The render node exists and your user can open it:
```
$ ls -l /dev/dri/renderD128
crw-rw-rw-. 1 root render 226, 128 Oct 20 18:56 /dev/dri/renderD128
```
Expected: a character device. Mode crw-rw-rw- here, so no group membership is needed. Every command below uses /dev/dri/renderD128, the only render node on this box. With two GPUs, find the AMD node and change the path in both scripts and in the ffmpeg commands; for mpv's vaapi-copy the mpv manual names --vaapi-device [UNVERIFIED: single-GPU box].
Placeholders: none.
Backups: none needed. The package adds its VA drivers and its own libgallium under /usr/lib64/dri-freeworld/, one file in /etc/ld.so.conf.d/, and license and metainfo files; its install scriptlet runs ldconfig, which rebuilds the linker cache. Fedora's Mesa packages stay installed (steps 7 and 10).

Steps#

Save the two scripts in an empty directory and work there.

mkdir -p ~/vaapi-test && cd ~/vaapi-test

Download amdgpu_video_caps.py and va_profiles.py from this page, or copy them from here. The first asks the amdgpu kernel driver through libdrm, the second asks libva.

amdgpu_video_caps.py:

# What the amdgpu kernel driver says the video block can do (AMDGPU_INFO_VIDEO_CAPS).
import ctypes, os
from ctypes import POINTER, byref, c_uint32, c_void_p, sizeof

class CodecInfo(ctypes.Structure):
    _fields_ = [(f, c_uint32) for f in
                ("valid", "max_width", "max_height", "max_pixels_per_frame", "max_level", "pad")]

class VideoCaps(ctypes.Structure):
    _fields_ = [("codec_info", CodecInfo * 8)]

CODECS = ["MPEG2", "MPEG4", "VC1", "H264", "HEVC", "JPEG", "VP9", "AV1"]
lib = ctypes.CDLL("libdrm_amdgpu.so.1")
lib.amdgpu_device_initialize.argtypes = [ctypes.c_int, POINTER(c_uint32), POINTER(c_uint32), POINTER(c_void_p)]
lib.amdgpu_query_video_caps_info.argtypes = [c_void_p, ctypes.c_uint, ctypes.c_uint, c_void_p]

fd = os.open("/dev/dri/renderD128", os.O_RDWR)
major, minor, dev = c_uint32(), c_uint32(), c_void_p()
assert lib.amdgpu_device_initialize(fd, byref(major), byref(minor), byref(dev)) == 0

for kind, cap_type in (("decode", 0), ("encode", 1)):
    caps = VideoCaps()
    assert lib.amdgpu_query_video_caps_info(dev, cap_type, sizeof(caps), byref(caps)) == 0
    print(f"{kind}:")
    for name, c in zip(CODECS, caps.codec_info):
        if c.valid:
            print(f"  {name:5} {c.max_width}x{c.max_height} level {c.max_level}")

va_profiles.py:

# What the VA-API driver that libva actually loads offers, per profile.
import ctypes, os
from ctypes import POINTER, byref, c_char_p, c_int, c_void_p

va = ctypes.CDLL("libva.so.2")
va_drm = ctypes.CDLL("libva-drm.so.2")
va_drm.vaGetDisplayDRM.restype = c_void_p
va_drm.vaGetDisplayDRM.argtypes = [c_int]
va.vaInitialize.argtypes = [c_void_p, POINTER(c_int), POINTER(c_int)]
va.vaQueryVendorString.restype = c_char_p
va.vaQueryVendorString.argtypes = [c_void_p]
va.vaMaxNumProfiles.argtypes = [c_void_p]
va.vaMaxNumEntrypoints.argtypes = [c_void_p]
va.vaQueryConfigProfiles.argtypes = [c_void_p, POINTER(c_int), POINTER(c_int)]
va.vaQueryConfigEntrypoints.argtypes = [c_void_p, c_int, POINTER(c_int), POINTER(c_int)]
va.vaProfileStr.restype = c_char_p
va.vaProfileStr.argtypes = [c_int]
va.vaEntrypointStr.restype = c_char_p
va.vaEntrypointStr.argtypes = [c_int]

dpy = va_drm.vaGetDisplayDRM(os.open("/dev/dri/renderD128", os.O_RDWR))
major, minor = c_int(), c_int()
assert va.vaInitialize(dpy, byref(major), byref(minor)) == 0
print(va.vaQueryVendorString(dpy).decode())

profiles, n = (c_int * va.vaMaxNumProfiles(dpy))(), c_int()
va.vaQueryConfigProfiles(dpy, profiles, byref(n))
for p in profiles[:n.value]:
    eps, m = (c_int * va.vaMaxNumEntrypoints(dpy))(), c_int()
    va.vaQueryConfigEntrypoints(dpy, p, eps, byref(m))
    names = [va.vaEntrypointStr(e).decode().removeprefix("VAEntrypoint") for e in eps[:m.value]]
    print(f"  {va.vaProfileStr(p).decode().removeprefix('VAProfile'):26} {' '.join(names)}")

Neither writes anything. Both open /dev/dri/renderD128 and print what comes back, using libdrm_amdgpu.so.1 (package libdrm) and libva.so.2 plus libva-drm.so.2 (package libva) through Python's ctypes. vainfo from libva-utils is the usual tool for the second list. It is not installed on this box, so its output is not shown here.

Ask the kernel which codecs the video block decodes.
```
$ python3 amdgpu_video_caps.py
decode:
  H264  4096x4096 level 52
  HEVC  8192x4352 level 186
  JPEG  16384x16384 level 0
  VP9   8192x4352 level 0
  AV1   8192x4352 level 0
encode:
  H264  4096x4096 level 0
  HEVC  8192x4352 level 0
  AV1   8192x4352 level 0
```
Expected: an HEVC line under decode:. This is the kernel's AMDGPU_INFO_VIDEO_CAPS answer, read with libdrm's amdgpu_query_video_caps_info(): the 780M decodes H.264 up to 4096x4096 and HEVC up to 8192x4352. The answer has no profile field, so it can't tell Main from Main 10; the driver's list in step 3 can. If there is no HEVC line under decode:, this manual doesn't apply to your GPU.
List what Fedora's own VA driver offers.
```
$ LIBVA_DRIVERS_PATH=/usr/lib64/dri python3 va_profiles.py
libva info: VA-API version 1.23.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_23
libva info: va_openDriver() returns 0
Mesa Gallium driver 26.2.5 for AMD Radeon 780M Graphics (radeonsi, phoenix, ACO, DRM 3.64, 7.2.10-200.fc44.x86_64)
  JPEGBaseline               VLD
  VP9Profile0                VLD
  VP9Profile2                VLD
  AV1Profile0                VLD EncSlice
  None                       VideoProc
```
Expected: no H264… line and no HEVC… line. Fedora's driver decodes JPEG, VP9 and AV1 (VLD) and encodes AV1 (EncSlice). The GPU has HEVC (step 2), the driver build doesn't offer it. Fedora's mesa.spec passes no -Dvideo-codecs, so Mesa's default all_free applies, which Mesa's build options describe as enabling the codecs that aren't patent-encumbered.

LIBVA_DRIVERS_PATH replaces libva's driver search list (colon-separated). Fedora builds libva to search /usr/lib64/dri-nonfree, then /usr/lib64/dri-freeworld, then /usr/lib64/dri. On a box without freeworld, plain python3 va_profiles.py tries the first two and loads the same Fedora file. With the variable set to /usr/lib64/dri, the command lists Fedora's driver even after step 8, which is how this page's "before" transcripts were made (Field notes).

Generate three 2-second test clips.

ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30 -t 2 -c:v libx265 -pix_fmt yuv420p10le main10.mkv
ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30 -t 2 -c:v libx265 -pix_fmt yuv420p main8.mkv
ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30 -t 2 -c:v libsvtav1 -pix_fmt yuv420p av1.mkv

$ ls -l main10.mkv main8.mkv av1.mkv
-rw-r--r--. 1 user user 1497381 Oct 25 16:24 av1.mkv
-rw-r--r--. 1 user user 1215321 Oct 25 16:24 main10.mkv
-rw-r--r--. 1 user user 1205903 Oct 25 16:24 main8.mkv

Expected: three files of 1.2 to 1.5 MB here: HEVC Main 10, HEVC Main (8-bit), and AV1 as the control. libx265 and libsvtav1 are software encoders, so this step doesn't depend on the VA driver, and no sample downloads are needed. ffmpeg's decode log names each clip's codec and profile (the Stream #0:0: Video: line in step 5).

Decode the Main 10 clip through VA-API with Fedora's driver.

$ LIBVA_DRIVERS_PATH=/usr/lib64/dri ffmpeg -hide_banner -v verbose -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i main10.mkv -f null -
[…]
  Stream #0:0: Video: hevc (Main 10), 1 reference frame, yuv420p10le(tv, progressive, left), 1920x1080 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 1k tbn
[…]
[VAAPI @ 0x5604256d4140] libva: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
[…]
[VAAPI @ 0x5604256d4140] VAAPI driver: Mesa Gallium driver 26.2.5 for AMD Radeon 780M Graphics (radeonsi, phoenix, ACO, DRM 3.64, 7.2.10-200.fc44.x86_64).
[…]
[hevc @ 0x5604257bec40] No support for codec hevc profile 2.
[hevc @ 0x5604257bec40] Failed setup for format vaapi: hwaccel initialisation returned error.
[graph -1 input from stream 0:0 @ 0x7fb718004e80] w:1920 h:1080 pixfmt:yuv420p10le tb:1/1000 fr:30/1 sar:1/1 csp:unknown range:tv alpha:unspecified
[…]
[in#0/matroska,webm @ 0x5604256cc580]   Input stream #0:0 (video): 60 packets read (1211848 bytes); 60 frames decoded; 0 decode errors;
[…]
Exiting with exit code 0

Expected with Fedora's driver: No support for codec hevc profile 2., then Failed setup for format vaapi: hwaccel initialisation returned error. Profile 2 is libavcodec's number for HEVC Main 10, profile 1 is Main: main8.mkv fails the same way with profile 1 (Failure modes, row 2). ffmpeg then decodes all 60 frames in software. The filter graph gets pixfmt:yuv420p10le, a CPU pixel format.

Gotchaffmpeg exits 0 on the software fallback

A failed hwaccel setup doesn't fail the ffmpeg run. ffmpeg drops VA-API, decodes in software, and ends with 0 decode errors and Exiting with exit code 0, the same as the working run in step 12. An exit-code test passes on both. Look for the Failed setup line, and, with -hwaccel_output_format vaapi as here, for pixfmt:vaapi on the graph -1 input line.

Decode the AV1 control clip with the same driver.

$ LIBVA_DRIVERS_PATH=/usr/lib64/dri ffmpeg -hide_banner -v verbose -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i av1.mkv -f null -
[…]
[VAAPI @ 0x555fc65982c0] libva: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
[…]
[graph -1 input from stream 0:0 @ 0x7f2d10004ec0] w:1920 h:1080 pixfmt:vaapi tb:1/1000 fr:30/1 sar:1/1 csp:unknown range:tv alpha:unspecified
[…]
[in#0/matroska,webm @ 0x555fc6585580]   Input stream #0:0 (video): 60 packets read (1496364 bytes); 60 frames decoded; 0 decode errors;
[…]

Expected: no Failed setup line, and pixfmt:vaapi: the frames come out of the GPU as VA surfaces. The render node, libva and Fedora's driver work. Only the codec list is short.

Dry-run the install.

sudo dnf install --assumeno mesa-va-drivers-freeworld

Expected: one package to install, mesa-va-drivers-freeworld, and nothing to remove or downgrade. --assumeno answers no at the prompt, so nothing changes. On this box dnf's own log (/var/log/dnf5.log) names the run dnf install --assumeno mesa-va-drivers-freeworld. The terminal output, with the repository loading cut:

[…]
Repositories loaded.
Package                    Arch   Version         Repository                  Size
Installing:
 mesa-va-drivers-freeworld x86_64 0:26.2.5-1.fc44 rpmfusion-free-updates  53.0 MiB

Transaction Summary:
 Installing:         1 package

Total size of inbound packages is 14 MiB. Need to download 14 MiB.
After this operation, 53 MiB extra will be used (install 53 MiB, remove 0 B).
Operation aborted by the user.

Install it.

sudo dnf install mesa-va-drivers-freeworld

Expected: the one-package transaction from step 7, then Complete!. Here dnf's log names the install dnf install -y mesa-va-drivers-freeworld, so there was no confirmation prompt. The terminal output:

[…]
Package                    Arch   Version         Repository                  Size
Installing:
 mesa-va-drivers-freeworld x86_64 0:26.2.5-1.fc44 rpmfusion-free-updates  53.0 MiB
[…]
Running transaction
[1/3] Verify package files              100% |  21.0   B/s |   1.0   B |  00m00s
[2/3] Prepare transaction               100% |   1.0   B/s |   1.0   B |  00m01s
[3/3] Installing mesa-va-drivers-freewo 100% |  33.7 MiB/s |  53.0 MiB |  00m02s
Complete!

The package is RPM Fusion's build of the same Mesa version with -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec,av1dec,av1enc,vp9dec, installed into /usr/lib64/dri-freeworld/, the directory libva tries before Fedora's.

Check the installed package.

$ rpm -qi mesa-va-drivers-freeworld | grep -E "^(Version|Release|Install Date|Size|Vendor)"
Version     : 26.2.5
Release     : 1.fc44
Install Date: Sun 25 Oct 2026 04:01:19 PM EET
Size        : 55577925
Vendor      : RPM Fusion

$ dnf repoquery --installed --qf "%{name} %{from_repo}\n" mesa-va-drivers-freeworld
mesa-va-drivers-freeworld rpmfusion-free-updates

Expected: vendor RPM Fusion, the same version as mesa-dri-drivers (26.2.5 in Before you start), and an RPM Fusion repo. Size is in bytes: 55577925 is the 53 MiB from step 7.

Check that both drivers are on disk.
```
$ rpm -qf /usr/lib64/dri/radeonsi_drv_video.so /usr/lib64/dri-freeworld/radeonsi_drv_video.so
mesa-dri-drivers-26.2.5-1.fc44.x86_64
mesa-va-drivers-freeworld-26.2.5-1.fc44.x86_64
```
Expected: Fedora's file still belongs to mesa-dri-drivers, the new one to mesa-va-drivers-freeworld. Nothing of Fedora's was replaced. libva finds the freeworld file first.

List the profiles libva loads now.

$ python3 va_profiles.py
libva info: VA-API version 1.23.0
libva info: Trying to open /usr/lib64/dri-nonfree/radeonsi_drv_video.so
libva info: Trying to open /usr/lib64/dri-freeworld/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_23
libva info: va_openDriver() returns 0
Mesa Gallium driver 26.2.5 for AMD Radeon 780M Graphics (radeonsi, phoenix, ACO, DRM 3.64, 7.2.10-200.fc44.x86_64)
  H264ConstrainedBaseline    VLD EncSlice
  H264Main                   VLD EncSlice
  H264High                   VLD EncSlice
  HEVCMain                   VLD EncSlice
  HEVCMain10                 VLD EncSlice
  VP9Profile0                VLD
  VP9Profile2                VLD
  AV1Profile0                VLD EncSlice
  None                       VideoProc

Expected: libva stops at /usr/lib64/dri-freeworld/, and the list now has H264ConstrainedBaseline, H264Main, H264High, HEVCMain and HEVCMain10, each with VLD (decode) and EncSlice (encode). JPEGBaseline is gone: the freeworld build lists no JPEG decode profile (Notes).

Decode the HEVC clips again, without the variable.

$ ffmpeg -hide_banner -v verbose -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i main10.mkv -f null -
[…]
[VAAPI @ 0x55bc56360140] libva: Trying to open /usr/lib64/dri-nonfree/radeonsi_drv_video.so
[VAAPI @ 0x55bc56360140] libva: Trying to open /usr/lib64/dri-freeworld/radeonsi_drv_video.so
[VAAPI @ 0x55bc56360140] libva: Found init function __vaDriverInit_1_23
[VAAPI @ 0x55bc56360140] libva: va_openDriver() returns 0
[VAAPI @ 0x55bc56360140] Initialised VAAPI connection: version 1.23
[VAAPI @ 0x55bc56360140] VAAPI driver: Mesa Gallium driver 26.2.5 for AMD Radeon 780M Graphics (radeonsi, phoenix, ACO, DRM 3.64, 7.2.10-200.fc44.x86_64).
[…]
[graph -1 input from stream 0:0 @ 0x7f5fa4004ec0] w:1920 h:1080 pixfmt:vaapi tb:1/1000 fr:30/1 sar:1/1 csp:unknown range:tv alpha:unspecified
[…]
[in#0/matroska,webm @ 0x55bc56358580]   Input stream #0:0 (video): 60 packets read (1211848 bytes); 60 frames decoded; 0 decode errors;
[…]
Exiting with exit code 0

Expected: libva opens the freeworld driver, there is no No support or Failed setup line, and the graph input is pixfmt:vaapi: the GPU decoded the 60 frames. The 8-bit clip:

$ ffmpeg -hide_banner -v verbose -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i main8.mkv -f null -
[…]
[graph -1 input from stream 0:0 @ 0x7f9718004ec0] w:1920 h:1080 pixfmt:vaapi tb:1/1000 fr:30/1 sar:1/1 csp:unknown range:tv alpha:unspecified
[…]
[in#0/matroska,webm @ 0x56516b88e580]   Input stream #0:0 (video): 60 packets read (1202435 bytes); 60 frames decoded; 0 decode errors;
[…]

Expected: pixfmt:vaapi again.

The GPU wasn't to blame

Sun, 25 Oct 2026 00:00:00 +0000

TL;DR — On Fedora, Mesa (the open-source graphics stack) ships an AMD driver for VA-API (the interface Linux programs use to hand video decoding to the GPU) that offers no H.264 and no HEVC decode, although the GPU does both. Fedora's Mesa keeps upstream's video-codecs=all_free default, and all_free builds only the codecs without patent encumbrance. RPM Fusion, a third-party repository for Fedora, ships mesa-va-drivers-freeworld, which adds H.264 and HEVC back, and libva, the VA-API loader, loads it before Fedora's driver; 64-bit programs using Mesa's OpenGL get RPM Fusion's build too. When you test, ignore ffmpeg's exit code (it is 0 when ffmpeg falls back to decoding on the CPU; only the log says so), and don't test the mpv player's --hwdec=vaapi with --vo=null, which gives the GPU decoder no device, so mpv decodes in software (vaapi-copy works headless).

The typo followed the tag; the failures didn't

Sat, 24 Oct 2026 00:00:00 +0000

Assumes you've run a coding agent against a local llama-server. Builds on Flint mistyped its path and blamed the tools, from the 3090 Agent Bench.

Flint misspelled its own run folder 495 times on the A9. It typed runs-s2_flxr1 where the folder was runs-s2-flxr1: one underscore where the tag had a hyphen, up to 127 times in a single session. Six of the 18 Flint cells I counted did it. One of those six lost its task to the typo. When I renamed the run tag and ran the same task again, the typo moved. The scores didn't.

Three models wrote the same circuit-breaker bug

Thu, 22 Oct 2026 00:00:00 +0000

One README on the A9 says this about its circuit breaker:

An attempt that was already in flight when the circuit opened scores nothing: the open period is the point, and the trial is the only way out.

Swift-1.5 wrote that sentence, under Claude Code, as part of a TypeScript retry layer for a payments gateway. It is a precise statement of the right invariant. The code below it does not keep it: a request that left while the circuit was closed, and comes back during the half-open trial, decides the trial. The code reviewer called the sentence an overclaim. The honesty checker, which files the labels, called it honest: it read the sentence as a claim about the open state, where the code does keep it (how the labels work). Both readings fit what the code does. It handles the late request, for the wrong state.

The model said it saw no output. It was right.

Tue, 20 Oct 2026 00:00:00 +0000

Assumes you've driven a coding agent against a local llama.cpp server and know what a tool call is.

North-Mini-Code made eight tool calls in a Java task under Claude Code and gave every one of them the same id, 1. Claude Code ran all eight and logged eight real results. The model was shown one of them, a read error. Within a minute it decided the project directory was empty. From where it sat, that was correct.

Three bugs between K2 and a working Spring app

Tue, 20 Oct 2026 00:00:00 +0000

Assumes you've read a Spring Boot stack trace and know what an agent matrix cell is (part 13 has the setup).

An honesty table invites a lazy reading: the models with no lies on record must be the ones that can do the work. In this matrix that reading held up for a while. When these cells ran, Flash-Next IQ4_XS, the stage-1 leader, had 33 runs and zero lie cells.

A -> B -> C -> A: benchmarking a kernel cmdline change you have to reboot for

Fri, 16 Oct 2026 00:00:00 +0000

The third boot that afternoon changed nothing, on purpose. Same kernel, 7.2.9-300.fc45. Same command line, byte for byte. Same IOMMU group summary in its meta.txt: one DMA group, 32 DMA-FQ, two identity. It was the baseline boot again, run because the test plan said to, and its bench started about 22 minutes after the first baseline's.

gpt-oss-120b's Vulkan prefill at 64k context came out 6.2 % faster than on the first baseline boot.

One rebuild moved gpt-oss off ROCm. Two models stayed

Fri, 16 Oct 2026 00:00:00 +0000

Part 6 settled it by depth. gpt-oss-120b at 64k of context: ROCm prefilled 324 tok/s, Vulkan 131. By 127k the gap was 7×. The serving table put gpt-oss on ROCm, under a rule that fits in four words: ROCm for long context.

On the night of 15 October the queue built llama.cpp master for Vulkan, 132 commits past the host build behind parts 5 to 7, and ran both builds back to back. gpt-oss-120b at 64k, old build: 114.7 tok/s. New build: 355.9.

Seven FAILs, one setting: rerunning agents at 262144 tokens

Fri, 16 Oct 2026 00:00:00 +0000

A FAIL in the agent matrix reads like a verdict on the code. The agent wrote something, the hidden tests caught it, next row.

Three of the FAIL rows from the A9 score 100 points. Every hidden test passes in them, and every mutant is caught. The code is finished and correct. What failed was the session. Each one had grown to just under 131072 tokens of context when the next request crossed the line. The server refused it, and Claude Code exited with an error. The matrix grades that exit as well as the code.

The best-reviewed code came from the slowest Flash-Next arm

Thu, 15 Oct 2026 00:00:00 +0000

Same model, same six cells, two rows.

Row one: Flash-Next at IQ4_XS on llama.cpp Vulkan with MTP. 4 of 6 cells passed. Blind-review mean 3.17. 0.68 passes per hour of wall clock.

Row two: the same model squeezed into a 62 GiB Q2_0, on Strata's hcq8 mode. 6 of 6 passed. 3.96 passes per hour. Review mean 2.5, the lowest of any Flash-Next arm.

The pass column crowns the small quant. The review column says the slowest Flash-Next arm reviewed best. Both columns are measured correctly. Neither explains the other, because the two rows differ in four ways at once and each cell ran once.

Inventing the work vs promising what isn't there

Wed, 14 Oct 2026 00:00:00 +0000

After stage 1 the ask was simple: separate the models whose code is wrong from the models that say things that never happened. A rollback that exists and breaks is a bug. A test suite that exists only in the closing summary is something else.

That sounds like one more column in the results table. It took three labels, a keyword rule, consistency passes that changed five labels, and a ruling on what counts as a lie before the last column could be filled in.

IOMMU off buys a 128 GB iGPU 5 %, and costs the NPU