Performance comparison rv1126 vs rk3566/rk3568

[Consti10]

Hello, Has anybody done a comparison of h265 EN-coding performance of RV1126 compared to RK3566/68 ? Or are they all the same (encoding) hardware ? Since RV1126 is speced for 4K@30fps (And I was able to get up to 1080p90fps out of it) while RK3566/68 are speced for 1080p100fps.

We are mostly interested in how they both perform on high frame rates (1080p100+, 720p120+).

[HermanChen]

RV1126 encoder is 4K@30fps and RK3566/68 is 1080p@60fps in datasheet. The real performance should have some margin but it is not ensured in all the cases.

[Consti10]

Does this mean the info from the main website is wrong ? https://www.rock-chips.com/a/en/products/RK35_Series/2021/0113/1274.html

it says "Support 1080P 100fps H.265/H.264 encoder"

[HermanChen]

100fps is hardware design target. 60fps is the real rate that can achieve in all the cases. In some extreme case it will be 80+fps.

[Consti10]

Interesting. Are there architectural differences between rv1126 and rk3566/68 regarding the encoding unit ? From my testing, rv1126 can do 1080p 60 without problems. If you feed it 1080p90 (for example) it strugles a bit - but the issue seems fixable by sw (hw encoding time is well below 10ms target, but queing / enqueuing Buffers takes too much time)

[Consti10]

If anybody is interested - I've measured the encoding throughput on various resolutions on rv1126. Test method: 1) modify the mpi_enc_test file to only draw the pattern on the first 10 frames 2) measure the delta between each "encoding" step 3) fix encoder clock speed to max.

Results: For 3840x2160: Avg of frame delta: 25.881187 -> 38.63 fps

For 2560x1440: Avg of frame delta: 13.029703 -> 76.74 fps

For 1920x1080: Avg of frame delta: 11.465346 -> 87.219 fps

For 1280x720: Avg of frame delta: 6.485148 -> 154 fps

[Consti10]

If anybody has an rk356X chip, it'd be interesting to see your results.

[Consti10]

Regarding the "draw pattern only 10 times - code:"

uint64_t before=getTimeMs();
                // Consti10
                // fill only the first 10 frames, then do nothing to not mess up the benchmark with expensive CPU work
                if(p->frame_count<10){
                    ret=fill_image(buf,width,height,hor_stride,ver_stride,fmt,frame_count);
                }else{
                    ret=MPP_OK;
                }
                uint64_t deltaX=getTimeMs()-before;
                printf("Filling frame took: %lld ms\n",deltaX);

else the time it takes the CPU to draw the test pattern influences the benchmark (so to say).

[HermanChen]

Interesting. Are there architectural differences between rv1126 and rk3566/68 regarding the encoding unit ? From my testing, rv1126 can do 1080p 60 without problems. If you feed it 1080p90 (for example) it strugles a bit - but the issue seems fixable by sw (hw encoding time is well below 10ms target, but queing / enqueuing Buffers takes too much time)

The enqueue / dequeue interface will be changed later.

[HermanChen]

echo 0x100 > /sys/module/rk_vcodec/parameters/mpp_dev_debug And check the hardware timing.

[Consti10]

Hw timing is obviosly lower, but yet the new enqueu/deque interface is not available. The following numbers are from rv1126, same tests as above, but this time no average- just 1 "hw timing log" for each resolution. FPS values are therefore only "theoretical" For 3840x2160: [ 663.626049] ffbb0000.rkvenc: pid: 746, session: 738000d3, time: 23154 us 1000*1000/23154=43fps For 2560x1440: [ 705.203643] ffbb0000.rkvenc: pid: 749, session: 1029ba83, time: 10325 us 1000*1000/10325=97fps For 1920x1080: [ 736.342276] ffbb0000.rkvenc: pid: 753, session: f39833de, time: 8855 us 1000*1000/8855=112fps For 1280x720: [ 766.910863] ffbb0000.rkvenc: pid: 756, session: c7afa21f, time: 4403 us 1000*1000/4403=227fps