Re: [BUG] rkvdec-vdpu383-h264: wrong pixels at horizontal de-blocking edges y=4 and y=12

[Sebastian Reichel <sebastian.reichel@collabora.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4029 bytes --]

Hi,

On Tue, Oct 27, 2026 at 05:07:28PM +0100, valery bokov wrote:
> Hi all,
> 
> A follow-up to my previous mail about 0x27b00618: I now know what it
> is, and there is a much larger speed-up behind it.
> 
> What the register is:
> The Rockchip BSP (rockchip-linux kernel develop-6.1,
> drivers/video/rockchip/mpp/mpp_rkvdec2.c) maps the RK3576 decoder’s
> “regs” bank at 0x27b00100 with size 0x600. Before every decode,
> rkvdec_vdpu38x_run() programs three “cache reference” registers,
> offsets relative to that base:
> 
> RKVDEC_REG_CLR_CACHE0_BASE   +0x510 (0x27b00610) = 1
> RKVDEC_REG_MAX_READS         +0x518 (0x27b00618) = 0x1c
> RKVDEC_REG_CACHE0_SIZE_BASE  +0x51c (0x27b0061c) = CACHEABLE_ACCESS |
>                                                    READ_ALLOCATE |
>                                                    LINE_SIZE_64_BYTES
>                                                  = 0x13
> 
> So 0x618 is MAX_READS. Mainline maps only 0x100-0x5ff of this bank and
> writes none of the three, so they keep their power-up values. On our
> board 0x618 comes up as 0x0 or 0x2 (the slow/fast lottery from my last
> mail), and 0x61c as 0x1 or 0x111. The READ_ALLOCATE bit was clear in
> all eight dumps.
> 
> Measurements:
> Same setup as before (Smatek T10PE / RK3576S, 6.18.34 with Simon’s
> priming patch, GStreamer 1.28.2 v4l2slh264dec). The full 654-frame
> 2688x1520 High-profile clip was decoded with sync=false, all within
> one power-up held with power/control=on, changing the registers
> between runs. Each setting was run twice with identical results:
> 
> 0x610  0x618  0x61c    ms/frame   fps
> -           0x0      -               65.4        15   (slow power-up,
> earlier runs)
> 0x0      0x2      0x111       22.5         44   (fast power-up)
> 0x0      0x1c    0x111       7.2           139
> 0x0      0x2      0x13        8.6           117
> 0x0      0x1c    0x13        3.6            ~278  (BSP values)
> 
> 0x610 reads back 0 after the write, so it appears to be self-clearing.
> The fps figures include gst-launch start-up, so the fastest rows are
> slight underestimates.
> 
> With the BSP values the decoder is about 18x faster than a slow
> power-up and about 6x faster than a fast one. MAX_READS and the
> read-allocate cache each contribute, and the effects combine. This may
> account for a good part of the mainline-vs-BSP gap noted in Simon’s
> FIX.md (4K ~30 fps vs ~112 fps).
> 
> Correctness:
> For each register setting I hashed every decoded picture
> (v4l2slh264dec ! videoconvert ! NV12 ! fdsink | md5sum, so buffer
> padding cannot affect the hash). All five settings gave the same md5
> over the whole clip, and no kernel errors were logged. Two caveats:
> 
> I cleared the cache once, while the BSP clears it before every frame.
> The clip still decoded identically, but I would not rely on that for
> other streams.
> The md5 shows the settings agree with each other; I did not compare
> against a software decoder in this run.
> 
> Suggested fix (not written yet):
> 
> Extend the VDPU383 “function” reg range in the RK3576 DT to 0x600, as
> the BSP does; or map 0x27b00610-0x27b0061f separately.
>
> Program the three registers like rkvdec_vdpu38x_run() does: before
> every decode run (not only at runtime resume), with CLR_CACHE0 = 1,
> MAX_READS = 0x1c, and CACHE0_SIZE_BASE = 0x13.
> 
> I’d appreciate a view from the maintainers on the preferred way to map
> the range.

It is already mapped separately in DT, the driver just does not get
this extra range, since it does not use any registers in it. But this
should work:

void __iomem *cache = devm_platform_ioremap_resource_byname(pdev, "cache");

> I’m happy to test patches on this board.

I suggest you write and test the patch and then send the patch :)
Ideally use https://b4.docs.kernel.org/ for this, which helps to
avoid common mistakes in the submission process.

Greetings,

-- Sebastian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip