[x86-64] 3D Support builds for AMD graphics

ht2tweak, I measured the sharpness question on the NUC (RX 7600, round 20) instead of judging by eye: Kodi screenshot of one eye in the frame-packed mode, compared pixel for pixel with the source frame of the "3D FSBS Resolution Pattern" test clip, and with half-SBS/half-TAB versions of the same pattern.

Full-resolution content (MVC, full SBS, full TAB) is pixel-exact on AMD: no shift, no resampling, every line-pair block identical to the source. So for a Blu-ray MVC rip there is nothing to sharpen on the Kodi side.

Half SBS and half TAB are a different story. Each eye is upscaled 2x, and on AMD that upscale is plain bilinear no matter what "Video scaling method" you pick. Lanczos3 and spline36 are silently ignored (kodi.log says "chosen scaling method 9, is not supported by renderer"). The reason is a Kodi bug, not a driver limit: the "HQ scalers for scaling above 20 %" check looks at the whole 1920-wide frame going to a 1920-wide eye viewport and concludes 0 % scaling, while the eye is really stretched from 960 to 1920. That check is in upstream Kodi's GL and GLES renderers, so it affects every x86 build, not just this one.

Workaround until it is fixed: set Video scaling method to Lanczos3 (or spline36) AND set "Enable HQ scalers for scaling above" to 0 %. Both are needed. With that, the finest lines the half-res pattern can still carry come out at 67 of 255 contrast instead of 47, which is what a proper Lanczos upscale gives.

The Pi does not go through Kodi's GL scaler at all: the video plane is cropped per eye and the HVS scales it in hardware, with a multi-tap filter. AMD cannot use that path for software-decoded MVC (its planes only take NV12/P010, see xbmc issue 29160), so it lands on the GL path. That explains a Pi > AMD difference on half-res material, and predicts none on full-res. I have not measured the Pi myself.

Maybe I will send a fix to Kodi upstream.

Prepared with Claude Code (Anthropic).

Good to know, and it narrows things down. The measurement says Kodi on AMD hands the display driver a frame identical to the decoded source, so for full-res content the difference you and vobs see has to come after that point: what goes out on the wire, or what the projector does with it. Two candidates, both measurable without eyes:

(1) Link format. The Pi normally sends 8-bit RGB in frame packing; the AMD box can be on 10 or 12-bit, or YCbCr, and a projector may process those differently. If you have an HDMI analyser or your projector shows an input info page, the format, bit depth and colour space for each source would settle this.

(2) Chroma reconstruction. The source is 4:2:0. On AMD, Kodi's GL shader rebuilds the chroma with bilinear sampling before the frame reaches the wire; on the Pi the HVS does it in hardware. That changes colour edges only, never luma edges. I can measure the AMD side with a coloured pattern.

So one question back: is the Pi sharper on a pure luma pattern (the black and white line blocks of "3D MVC Resolution Pattern"), or only on coloured content? That alone separates 1 from 2.

Prepared with Claude Code (Anthropic).