10:18 <Ermine> Is it good idea to use 16K page size on Rockchip hardware?

10:22 <CounterPillow> is it a good idea on any hardware?

10:23 <Ermine> Asahi uses 16K pages, and iirc performance was among the reasons they use them

10:23 <Ermine> (the other reason being Mac hardware expecting 16K pages or something like that)

10:27 <Dex2x> the rpi as well?

10:27 <CounterPillow> it's arguable whether it's a good idea there because now when they want to do x86 emulation they also have to translate page sizes, which is an additional layer

10:28 <CounterPillow> I'm also not convinced it's a good idea for performance on low memory system because I'd imagine having a larger page size will result in a lot more fragmentation

10:29 <Dex2x> low memory being < 4G ?

10:30 <CounterPillow> but these are things you can measure for your specific workload I'd imagine, and then do actual statistical analysis on the results so you're not just going off vibes

10:44 <diederik> I've read somewhere (phoronix?) that it gave a slight performance boost ... on systems with 192GB RAM ...

10:46 <diederik> "the other reason" is AFAICT the whole reason they went with 16K page size ... because the HW only supports 16K page size

11:02 <Ermine> CounterPillow: indeed

11:24 <Dex2x> wait does the RPiOS not default to 16k for the rpi5 ?

11:28 <Dex2x> and if I am reading this datasheet correctly the RK3588 support 4k and 64k page size MMU's

11:29 <Dex2x> oh that's the GPU

11:49 <chewitt> RPi5 uses 16K pages

11:49 <chewitt> https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/RPi/devices/RPi5/linux/linux.aarch64.conf#L406

11:50 <chewitt> It can also use 4K but the default (for a few reasons, one of which is performance) is 16K

11:53 <chewitt> Kwiboo: can I ask you to have a look at the 'rockchip-old' patchset on Linux 6.17.0 .. there are a few patch conflicts with upstream changes

11:54 <Dex2x> I don't think any of the rockchips support 16k?

11:54 <Dex2x> I think I had boot failures when I tried to compile for 16k with armbian

11:57 <chewitt> detlevc: ping!

11:57 <chewitt> I spotted these when looking more closely at the 'v3' patches in your Linux repo: https://github.com/chewitt/linux/commit/528645b72033a717fa8ba6aaf01ac38657fca060

11:58 <chewitt> I'm also seeing a performance difference between RK3588 and RK3576

11:59 <chewitt> 3588 can play Jellyfish test files <= 300mbps without issues

11:59 <chewitt> (both HEVC, HEVC 10-bit and H264)

11:59 <chewitt> 3576 manages <= 15mbps

12:01 <chewitt> 356X implemented by borrowing large amounts of the your vdpu381 decoder, manages <= 10mbps

12:02 <chewitt> that seems rather low compared to 3588

12:02 <chewitt> so I'm wondering if that's a known thing, or if there's any ideas on what the issue might be?

12:54 <detlevc> chewitt That branch is probably not completely ready yet (And mostly tested on 3588 only so far). But yes, that is a big performance difference and I don't think there is that much more setup code. I can do some tracing later this week and see what the hardware does

12:56 <chewitt> detlevc I did notice that the vendor kernel has 'hacks' for 3576 (and 356X)

12:56 <chewitt> e.g. https://github.com/rockchip-linux/kernel/blob/develop-6.6/drivers/video/rockchip/mpp/hack/mpp_hack_rk3576.c

13:01 <chewitt> i'm not sure if those are true hacks, or it's just trying to handle differences between vdpu346|381|383

13:01 <chewitt> 346 and 381 generally look to be quite similar

13:02 <detlevc> chewitt I did use those hacks in the past but didn't see any difference between the 2

13:02 <detlevc> I mean with or without hacks

13:03 <chewitt> the 356x vendor dts mentioned standard and 'advanced' assigned-clock-rates

13:03 <chewitt> but fiddling with those didn't generate any difference, so it's not something simple like that

13:05 <chewitt> there's no mention of anything similar for 3576 or 3588 so perhaps it's just a leftover from older code

13:41 <ndufresne> chewitt: on 356X, the hacks was about quick transition from H.264 to another supported CODEC, I don't think there has been any look to that upstream yet

13:42 <chewitt> ahh, interesting

13:46 <ndufresne> so typically use case, of a random file playlist with transition quick enough so the IP isn't being suspended in between

13:46 <ndufresne> hopefully I understood that one correct

14:21 <chewitt> doesn't sound like it would be the source of any performance issues (as I've seen)

14:40 <ndufresne> No, for that I would start by checking if all the clocks are at their expected speed

14:41 <ndufresne> (note that mbps does not mean much in general)

14:42 <chewitt> the assigned-clock-rate(s) for 3576 match the vendor dts

14:42 <chewitt> same for 356x

14:42 <chewitt> the assumption is that the vendor dts is correct :)

14:42 <ndufresne> then check the AXI clocks, RAM speed, burst configuration

14:43 <ndufresne> I'm assuming you have measure the speed on vendor BSP to be better ?

14:43 <chewitt> I've never booted any RK board with a vendor image

14:44 <chewitt> I'm not sure if that's a badge of honour or not? :)

14:44 <ndufresne> chewitt: one thing special about rk3588 is that ram is fast, could be a difference, and that get solved by enabling AFBC (we aren't there yet though)

14:45 <ndufresne> chewitt: well, to develop these, whenever we can, we uplift vendor driver, so its easier to switch from one to another

14:46 <chewitt> I did spot a mention of 300Mhz 'max' somewhere in the 3568 TRM though

14:46 <chewitt> so you'd hope the vendor driver came somewhere near that

14:46 <ndufresne> RAM is slow on 356x, I once had a project that aborted because of that

14:49 <chewitt> even ye olde Amlogic S905 with DDR3 is able to play higher bitrate Jellyfish files than a 3576 board with LPDDR5

14:50 <chewitt> i'll need to learn some tricks to do actual scientific tests, but that alone suggests something is off..

15:20 <ndufresne> But you are testing performance with the display path, how can you know this isn't display related ?

15:21 <ndufresne> I can tell you how to isolate and performance test the codecs using GStreamer, but I don't know exactly how that works with ffmpeg (should be feasible)