hbiyik / FFmpeg

PLEASE USE https://github.com/nyanmisaka/ffmpeg-rockchip REPO INSTEAD.
https://github.com/nyanmisaka/ffmpeg-rockchip
Other
89 stars 7 forks source link

Open Test Thread #14

Open hbiyik opened 1 year ago

hbiyik commented 1 year ago

@avafinger

A lot has been added specially hevc and vp8 encoders with scaling support:

https://github.com/hbiyik/FFmpeg/wiki

should be stable to test if you are interested.

kyak commented 9 months ago

@hbiyik i confirm that it works now with kodi (no green screen). Thank you!

hbiyik commented 9 months ago

thank you for testing, please abuse the decoder as much as possible. I was aware that black screen in ffplay, my first thought was that it would be a bug in ffplay since it works in other players (ie:mpv) though, only ffplay has this issue. I think there is some deadlock somewhere, but i am not so sure, i will check it in detail,

nyanmisaka commented 9 months ago

@hbiyik I managed to boot into the tty on rock-5a. 274E9AB8-9DAC-4B59-B02E-06E7727BA59E

hbiyik commented 9 months ago

@nyanmisaka nice, now the biggest problem for me, is that i need to find my sdcard, i am sure it is somewhere around but never know exactly where it is.

hbiyik commented 9 months ago

@nyanmisaka by tty you mean over uart right? does you hdmi work? i just compiled the image and used dts blindly but no hdmi output yet, only uart.

[alarm@alarm ~]$ sudo dmesg | grep panthor                                                                                                                                                                                                                                      
[sudo] password for alarm: 
[    0.000000] Linux version 6.7.0-rc1-panthor-gf81e9055e0b9 (alarm@alarm) (aarch64-unknown-linux-gnu-gcc (GCC) 12.1.0, GNU ld (GNU Binutils) 2.38) #1 SMP PREEMPT Wed Nov 15 01:40:50 UTC 2023
[   20.689884] panthor fb000000.gpu: [drm] clock rate = 198000000
[   20.691049] panthor fb000000.gpu: [drm:panthor_devfreq_init [panthor]] Failed to register cooling device
[   20.692651] panthor fb000000.gpu: [drm] mali-g610 id 0xa867 major 0x0 minor 0x0 status 0x5
[   20.693371] panthor fb000000.gpu: [drm] Features: L2:0x7120306 Tiler:0x809 Mem:0x301 MMU:0x2830 AS:0xff
[   20.694188] panthor fb000000.gpu: [drm] shader_present=0x50005 l2_present=0x1 tiler_present=0x1
[   20.722237] panthor fb000000.gpu: [drm] Firmware protected mode entry not be supported, ignoring
[   20.723182] panthor fb000000.gpu: [drm] CSF FW v1.1.0, Features 0x0 Instrumentation features 0x71
[   20.724144] [drm] Initialized panthor 1.0.0 20230801 for fb000000.gpu on minor 1
[alarm@alarm ~]$ uname -a
Linux alarm 6.7.0-rc1-panthor-gf81e9055e0b9 #1 SMP PREEMPT Wed Nov 15 01:40:50 UTC 2023 aarch64 GNU/Linux
nyanmisaka commented 9 months ago

Nope, HDMI works for me. I'm just using the ubuntu-server image. Note that only the first HDMI 8K port is registered in the device tree.

hbiyik commented 9 months ago

ok let me dig into this

nyanmisaka commented 9 months ago

Screenshot from 2023-11-16 14-31-41

hbiyik commented 9 months ago

ok hdmi also came up when unplug the first default input in the same monitor, (rock5 was the 2nd input), i think hdmi must be turned on when the kernel boots otherwise it crashes, i also had some crashes when switching the hdmi out from one to another in the rock5b, but yeah now i have at least a running monitor over hdmi.

edit: also crashes when i power off and on the monitor.

[ 1055.513677] dwhdmi-rockchip fde80000.hdmi: don't use dsc mode
[ 1055.514045] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514063] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514077] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514091] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514106] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514120] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514134] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514148] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514162] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.514176] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[ 1055.730089] dwhdmi-rockchip fde80000.hdmi: dw hdmi qp use tmds mode
[ 1055.746967] dwhdmi-rockchip fde80000.hdmi: use tmds mode
[ 1055.777031] Console: switching to colour frame buffer device 240x67
[ 1055.780257] dwhdmi-rockchip fde80000.hdmi: use tmds mode
[ 1055.823702] rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device
[ 1070.563649] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP
[ 1070.564376] Modules linked in: panthor fusb302 r8169 tcpm drm_gpuvm cfg80211 crct10dif_ce typec drm_exec drm_shmem_helper pwm_fan gpu_sched rtc_hym8563 rfkill rockchip_thermal fuse dm_mod ip_tables x_tables ipv6
[ 1070.566063] CPU: 0 PID: 261 Comm: kworker/0:2 Not tainted 6.7.0-rc1-panthor-gf81e9055e0b9 #1
[ 1070.566802] Hardware name: Radxa ROCK 5 Model B (DT)
[ 1070.567238] Workqueue: pm pm_runtime_work
[ 1070.567601] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1070.568212] pc : rk_iommu_is_stall_active+0x24/0x58
[ 1070.568645] lr : rk_iommu_enable_stall+0x18/0x154
[ 1070.569061] sp : ffff8000832cbc20
[ 1070.569353] x29: ffff8000832cbc20 x28: 0000000000000000 x27: 0000000000000000
[ 1070.569984] x26: 0000000000000000 x25: 00000000000f4240 x24: ffff8000800dc928
[ 1070.570614] x23: 0000000000000000 x22: ffff000002d440f4 x21: 0000000000000008
[ 1070.571244] x20: ffff8000807becdc x19: ffff000002cb2380 x18: 0000000000000000
[ 1070.571875] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000
[ 1070.572505] x14: 0000000000000004 x13: ffff0000051ea1f0 x12: 0000000000000000
[ 1070.573134] x11: ffff000006776c58 x10: ffff000006776b58 x9 : 0000000000000000
[ 1070.573764] x8 : ffff800081aa4000 x7 : ffff000004aac200 x6 : 000000060308eca0
[ 1070.574394] x5 : 00000000000000c0 x4 : ffff000002cb2380 x3 : 0000000000000000
[ 1070.575022] x2 : 0000000000000000 x1 : ffff800081e05e04 x0 : 0000000000000001
[ 1070.575653] Call trace:
[ 1070.575869]  rk_iommu_is_stall_active+0x24/0x58
[ 1070.576271]  rk_iommu_disable+0x2c/0x1b0
[ 1070.576619]  rk_iommu_suspend+0x2c/0x44
[ 1070.576959]  pm_generic_runtime_suspend+0x2c/0x44
[ 1070.577377]  __rpm_callback+0x48/0x1dc
[ 1070.577709]  rpm_callback+0x6c/0x78
[ 1070.578017]  rpm_suspend+0x104/0x564
[ 1070.578333]  pm_runtime_work+0xc4/0xc8
[ 1070.578665]  process_one_work+0x138/0x248
[ 1070.579023]  worker_thread+0x320/0x438
[ 1070.579355]  kthread+0x114/0x118
[ 1070.579643]  ret_from_fork+0x10/0x20
[ 1070.579966] Code: 52800020 f9400481 f862d821 91001021 (b9400021) 
[ 1070.580500] ---[ end trace 0000000000000000 ]---

also you are on llvmpipe is this mesa-panthor?

nyanmisaka commented 9 months ago

Could it be a resolution or refresh rate specific issue? I have a 1080p60 screen for testing, and whenever I plug in and unplug HDMI, it never crashes the kernel.

[   14.087418] rockchip-drm display-subsystem: bound fdd90000.vop (ops rockchip_drm_fini [rockchipdrm])
[   14.087522] dwhdmi-rockchip fde80000.hdmi: supply avdd-0v9 not found, using dummy regulator
[   14.087607] dwhdmi-rockchip fde80000.hdmi: supply avdd-1v8 not found, using dummy regulator
[   14.089702] dwhdmi-rockchip fde80000.hdmi: registered ddc I2C bus driver
[   14.089805] rockchip-drm display-subsystem: bound fde80000.hdmi (ops rockchip_drm_fini [rockchipdrm])
[   14.090652] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0
[   14.090784] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.091180] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.091393] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.091505] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.091614] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.194957] dwhdmi-rockchip fde80000.hdmi: i2c read time out!
[   14.194980] dwhdmi-rockchip fde80000.hdmi: failed to get edid
[   14.203258] dwhdmi-rockchip fde80000.hdmi: use tmds mode
[   14.203375] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx_ropll_cmn_config bus_width:16a8c8 rate:1485000
[   14.203651] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy pll locked!
[   14.203673] dwhdmi-rockchip fde80000.hdmi: final tmdsclk = 148500000
[   14.203679] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: bus_width:0x16a8c8,bit_rate:1485000
[   14.203872] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy lane locked!
[   14.203892] dwhdmi-rockchip fde80000.hdmi: don't use dsc mode
[   14.204297] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204317] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204328] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204338] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204348] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204358] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204368] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204378] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204388] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.204398] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
[   14.411020] dwhdmi-rockchip fde80000.hdmi: dw hdmi qp use tmds mode
[   14.420749] Console: switching to colour frame buffer device 240x67
[   14.420812] dwhdmi-rockchip fde80000.hdmi: use tmds mode
[   14.442443] rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device
[   14.453924] dwhdmi-rockchip fde80000.hdmi: use tmds mode
[   14.472089] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.472403] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.472661] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.473446] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.473802] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   14.473816] dwhdmi-rockchip fde80000.hdmi: failed to get edid
[   14.487294] dwhdmi-rockchip fde80000.hdmi: use tmds mode
[   14.520489] dwhdmi-rockchip fde80000.hdmi: use tmds mode
[   19.295052] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   19.295401] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   19.295679] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   19.295896] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   19.296112] dwhdmi-rockchip fde80000.hdmi: i2c read err!
[   19.296135] dwhdmi-rockchip fde80000.hdmi: failed to get edid
[   21.106249] rfkill: input handler disabled
[   22.186462] dwhdmi-rockchip fde80000.hdmi: use tmds mode

I am planning to switch to a newer distro. Many dependencies of the debian bookworm I am using do not satisfy mesa-panthor.

Also what about your SoC temperature, I observed it is much higher in mainline than in BSP.

hbiyik commented 9 months ago

come to arch :) i will upload the packages soon. My finger sensors say that it seems ok, but i will check with lm_sensors once again. But in past i was using it with a very hot NVME, so i can not compare myself, it was already hot.

hbiyik commented 9 months ago

i was also annoyed by the green/blue led blinking on rock5b like a discoball all the time.

hbiyik commented 9 months ago

@nyanmisaka what is you commandline to boot the kernel, may be there is something missinf there causing those hdmi crashes. CMA or something..

nyanmisaka commented 9 months ago
$ cat /proc/cmdline
root=UUID=0acc6243-3757-428e-a469-9af22f8ca979 rootwait rootfstype=ext4 splash plymouth.ignore-serial-consoles console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=03b100fa-8dfb-f642-9a15-bce3da18ff65 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1

The dev listed some quirks in this WIP hdmi driver.

https://github.com/nyanmisaka/linux-rockchip/commit/140267c1c11d90f4889e57ae6d58280b261081c0

nyanmisaka commented 9 months ago

Command lines like this can turn off the blue led. sudo sh -c "echo none > /sys/class/leds/blue\:status/trigger"

But AFAIK the green led on 5B cannot be controlled by software.

hbiyik commented 9 months ago

v10+panthor-v3+32b+g310+egl15+afrc+afbc v10+reg-cache

tested both above branches from boris's mesa, but gnome/gdm crashes at start.

i also had to patch to compile it properly.

diff --git a/src/egl/main/egldriver.h b/src/egl/main/egldriver.h
index 6c8ea71..51c111e 100644
--- a/src/egl/main/egldriver.h
+++ b/src/egl/main/egldriver.h
@@ -227,7 +227,7 @@
    /* for EGL_EXT_surface_compression */
    EGLBoolean (*QuerySupportedCompressionRatesEXT)(_EGLDisplay *disp,
                                                    _EGLConfig *config,
-                                                   const EGLint *attr_list,
+                                                   const EGLAttrib *attr_list,
                                                    EGLint *rates,
                                                    EGLint rate_size,
                                                    EGLint *num_rates);

otherwise does not compile and complains about long to int pointer mismatch

 [LNK] Process 1470 (gnome-shell) of user 1000 dumped core.

Stack trace of thread 1470:
#0  0x0000ffff62d1aaec panfrost_resource_set_damage_region (rockchip_dri.so + 0xd0aaec)
#1  0x0000ffff620f5384 dri_st_framebuffer_validate (rockchip_dri.so + 0xe5384)
#2  0x0000ffff621b8a18 st_framebuffer_validate (rockchip_dri.so + 0x1a8a18)
#3  0x0000ffff621b9680 st_api_make_current (rockchip_dri.so + 0x1a9680)
#4  0x0000ffff620f4ed4 dri_make_current (rockchip_dri.so + 0xe4ed4)
#5  0x0000ffff620f8c18 driBindContext (rockchip_dri.so + 0xe8c18)
#6  0x0000ffff7c25683c dri3_bind_context (libGLX_mesa.so.0 + 0x4683c)
#7  0x0000ffff7c245a08 MakeContextCurrent (libGLX_mesa.so.0 + 0x35a08)
#8  0x0000ffff87b233d0 n/a (libGLX.so.0 + 0x33d0)
#9  0x0000ffff87b23e90 n/a (libGLX.so.0 + 0x3e90)
#10 0x0000ffff87b25370 n/a (libGLX.so.0 + 0x5370)
#11 0x0000ffff8bff02e0 n/a (libmutter-cogl-13.so.0 + 0x802e0)
#12 0x0000ffff8bf9acdc cogl_display_setup (libmutter-cogl-13.so.0 + 0x2acdc)
#13 0x0000ffff8bf99c44 cogl_renderer_check_onscreen_template (libmutter-cogl-13.so.0 + 0x29c44)
#14 0x0000ffff8c7df188 n/a (libmutter-13.so.0 + 0x14f188)
#15 0x0000ffff8ca84324 n/a (libmutter-clutter-13.so.0 + 0x64324)
#16 0x0000ffff8cac1548 clutter_context_new (libmutter-clutter-13.so.0 + 0xa1548)
#17 0x0000ffff8c730874 n/a (libmutter-13.so.0 + 0xa0874)
#18 0x0000ffff8d0197c4 g_initable_new_valist (libgio-2.0.so.0 + 0x997c4)
#19 0x0000ffff8d0198d4 g_initable_new (libgio-2.0.so.0 + 0x998d4)
#20 0x0000ffff8c7ad544 n/a (libmutter-13.so.0 + 0x11d544)
#21 0x0000ffff8c7ac4e8 n/a (libmutter-13.so.0 + 0x11c4e8)
#22 0x0000ffff8c7ae5c0 meta_context_setup (libmutter-13.so.0 + 0x11e5c0)
#23 0x0000aaaab1eb23f0 n/a (gnome-shell + 0x23f0)
#24 0x0000ffff8c4c7b80 __libc_start_call_main (libc.so.6 + 0x27b80)
#25 0x0000ffff8c4c7c60 __libc_start_main_impl (libc.so.6 + 0x27c60)
#26 0x0000aaaab1eb2c70 n/a (gnome-shell + 0x2c70)
hbiyik commented 9 months ago

but the good news is kmscube is working, so i can use mpv to render directly over gbm. I think thats good enough for me to start working on poring mpp.

below are the PKGBUILDs in case of an interest

https://github.com/7Ji-PKGBUILDs/linux-panthor/blob/master/PKGBUILD https://github.com/7Ji-PKGBUILDs/mesa-panthor/blob/master/PKGBUILD

and finally Thermal values, but with an hot NVME:

bigcore0_thermal (/sys/devices/virtual/thermal/thermal_zone1/hwmon1)
    temp1: 50.85C
bigcore1_thermal (/sys/devices/virtual/thermal/thermal_zone2/hwmon2)
    temp1: 50.85C
center_thermal (/sys/devices/virtual/thermal/thermal_zone4/hwmon5)
    temp1: 50.85C
gpu_thermal (/sys/devices/virtual/thermal/thermal_zone5/hwmon6)
    temp1: 49.92C
littlecore_thermal (/sys/devices/virtual/thermal/thermal_zone3/hwmon4)
    temp1: 50.85C
npu_thermal (/sys/devices/virtual/thermal/thermal_zone6/hwmon7)
    temp1: 49.92C
pwmfan (/sys/devices/platform/pwm-fan/hwmon/hwmon3)
    pwm1: 100.00%
regulators
    dcdc-reg1 (vdd_gpu_s0): 0.68V (min: 0.55V, max: 0.95V, state: enabled, num_users: 2)
    dcdc-reg10 (vcc_1v8_s3): 1.80V (min: 1.80V, max: 1.80V, state: enabled, num_users: 1)
    dcdc-reg2 (vdd_cpu_lit_s0): 0.75V (min: 0.55V, max: 0.95V, state: enabled, num_users: 1)
    dcdc-reg3 (vdd_log_s0): 0.75V (min: 0.68V, max: 0.75V, state: enabled, num_users: 1)
    dcdc-reg4 (vdd_vdenc_s0): 0.75V (min: 0.55V, max: 0.95V, state: enabled, num_users: 1)
    dcdc-reg5 (vdd_ddr_s0): 0.85V (min: 0.68V, max: 0.90V, state: enabled, num_users: 1)
    dcdc-reg6 (vdd2_ddr_s3): 0.50V (state: enabled, num_users: 1)
    dcdc-reg7 (vdd_2v0_pldo_s3): 2.00V (min: 2.00V, max: 2.00V, state: enabled, num_users: 4)
    dcdc-reg8 (vcc_3v3_s3): 3.30V (min: 3.30V, max: 3.30V, state: enabled, num_users: 2)
    dcdc-reg9 (vddq_ddr_s0): 0.50V (state: enabled, num_users: 1)
    nldo-reg1 (vdd_0v75_s3): 0.75V (min: 0.75V, max: 0.75V, state: disabled, num_users: 1)
    nldo-reg2 (vdd_ddr_pll_s0): 0.85V (min: 0.85V, max: 0.85V, state: disabled, num_users: 1)
    nldo-reg3 (avdd_0v75_s0): 0.75V (min: 0.75V, max: 0.75V, state: disabled, num_users: 1)
    nldo-reg4 (vdd_0v85_s0): 0.85V (min: 0.85V, max: 0.85V, state: disabled, num_users: 1)
    nldo-reg5 (vdd_0v75_s0): 0.75V (min: 0.75V, max: 0.75V, state: disabled, num_users: 1)
    pldo-reg1 (avcc_1v8_s0): 1.80V (min: 1.80V, max: 1.80V, state: disabled, num_users: 1)
    pldo-reg2 (vcc_1v8_s0): 1.80V (min: 1.80V, max: 1.80V, state: disabled, num_users: 1)
    pldo-reg3 (avdd_1v2_s0): 1.20V (min: 1.20V, max: 1.20V, state: disabled, num_users: 1)
    pldo-reg4 (vcc_3v3_s0): 3.30V (min: 3.30V, max: 3.30V, state: disabled, num_users: 1)
    pldo-reg5 (vccio_sd_s0): 3.30V (min: 1.80V, max: 3.30V, state: disabled, num_users: 1)
    pldo-reg6 (pldo6_s3): 1.80V (min: 1.80V, max: 1.80V, state: disabled, num_users: 1)
    regulator@42 (vdd_cpu_big0_s0): 0.80V (min: 0.55V, max: 1.05V, state: enabled, num_users: 1)
    regulator@43 (vdd_cpu_big1_s0): 0.80V (min: 0.55V, max: 1.05V, state: enabled, num_users: 1)
    vcc-1v1-nldo-s3-regulator (vcc_1v1_nldo_s3): 1.10V (num_users: 6)
    vcc12v-dcin-regulator (vcc12v_dcin): 12.00V (num_users: 2)
    vcc3v3-pcie2x1l0-regulator (vcc3v3_pcie2x1l0): 3.30V (state: enabled, num_users: 2)
    vcc3v3-pcie2x1l2-regulator (vcc3v3_pcie2x1l2): 3.30V (num_users: 2)
    vcc3v3-pcie30-regulator (vcc3v3_pcie30): 3.30V (state: enabled, num_users: 1)
    vcc5v0-host-regulator (vcc5v0_host): 5.00V (state: enabled, num_users: 3)
    vcc5v0-sys-regulator (vcc5v0_sys): 5.00V (num_users: 23)
soc_thermal (/sys/devices/virtual/thermal/thermal_zone0/hwmon0)
    temp1: 50.85C
hbiyik commented 9 months ago

@nyanmisaka

first steps on the moon

[alarm@alarm ~]$ uname -a
Linux alarm 6.7.0-rc1-panthor-g4a610b4a1e08 #1 SMP PREEMPT Sat Nov 18 19:44:55 UTC 2023 aarch64 GNU/Linux
[alarm@alarm ~]$ ls /dev/mpp_service 
/dev/mpp_service
nyanmisaka commented 9 months ago

That’s awesome 👏 One day we should package it as a DKMS.

I don't know if mpp has a hard requirement for their custom dma-buf-heaps driver. Currently in 6.1 bsp this driver is broken, and the android ion driver has been removed by upstream linux, so the only available mem allocator is drm.

I experimented with the 6.1 bsp kernel, and with some fixes, it already has a high degree of completion. Backporting the panthor to it is also valuable. CB0C60DE-A425-4664-A925-26C20AA7C7D0

Yesterday I also encountered a system freeze in 6.7-rc1 caused by the hdmi screen being turned off.

hbiyik commented 9 months ago

it works!! :) (you need to get latest, i pushed some dts fixes.)

[alarm@alarm ~]$ sudo dmesg | grep mpp
[sudo] password for alarm: 
[    0.083389] mpp_service mpp-srv: c785ffa2ad90 author: boogie 2023-11-18 mpp: rkvenc2, remove devfreq support
[    0.083398] mpp_service mpp-srv: probe start
[    0.084611] mpp_service mpp-srv: probe success
[    0.358183] mpp_vdpu2 fdb50400.vdpu: Adding to iommu group 1
[    0.359279] mpp_vdpu2 fdb50400.vdpu: probe device
[    0.359853] mpp_vdpu2 fdb50400.vdpu: reset_group->rw_sem_on=0
[    0.360375] mpp_vdpu2 fdb50400.vdpu: reset_group->rw_sem_on=0
[    0.361343] mpp_vdpu2 fdb50400.vdpu: probing finish
[alarm@alarm ~]$ uname -a
Linux alarm 6.7.0-rc1-panthor-g4a610b4a1e08 #1 SMP PREEMPT Sat Nov 18 19:44:55 UTC 2023 aarch64 GNU/Linux

[alarm@alarm ~]$ ffmpeg -loglevel info -i h264_1080p_30_sdr.mp4 -an -sn -f null -
....
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 24559 kb/s, 30 fps, 30 tbr, 15360 tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
[h264_rkmpp_decoder @ 0xaaaaea88d0b0] Picture format is nv12.
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (h264_rkmpp_decoder) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
[h264_rkmpp_decoder @ 0xaaaaea88d0b0] Decoder noticed an info change
....

[alarm@alarm ~]$ journalctl -f 
Nov 18 22:23:56 alarm mpp[1566]: mpp_info: mpp version: 3b278438 author: Yandong Lin   2023-11-01 fix[hal_h265e_vepu541]: fix roi buffer variables incorrect use
hbiyik commented 9 months ago

but my panthor is completely broken.

hbiyik commented 9 months ago

That’s awesome 👏 One day we should package it as a DKMS.

I am not sure it is easy, because mpp is using alot of extra exported symbols from iommu_rockchip and someother variants of rockchip drivers. This should never be allowed in mainline. One option would be to use existing kernel interfaces to do similar operations but i am not that good at kernel development. I think the reason for mpp doing this is that, since it is controlled by user space sometimes it needs to reset itself and some other systems like mmu. You can see those operation in the history log, where i have cherry picked some commits from vendor kernel.

I don't know if mpp has a hard requirement for their custom dma-buf-heaps driver. Currently in 6.1 bsp this driver is broken, and the android ion driver has been removed by upstream linux, so the only available mem allocator is drm.

I do not guess so, i think drm device is just a wrapper around dma_buf_heap device, so drm device should be ok.

Backporting the panthor to it is also valuable.

Should be, because mainline is not the best when it comes to opp_select, pvtm, especially on the clock driver. The clock driver was very different than the vendor, i am not sure it is better or worse but the commit history was even completely different.

Some notes: I have disabled devfreq, qos, and dmc_lock operations in kernel, i do not knwo the exact impact but yeah, this is only a proof of concept at the moment, i will stop here i guess unless there is a working panthor.

Next target woudl be poritng RGA and i guess/hope it would be easier than mpp. But you know, nothing is easy with RGA.

kyak commented 9 months ago

@nyanmisaka @hbiyik can you guys please enlighten me about what's going on with panthor? Is it better than panfork? How is it related to panfrost? :)

I understand you are doing something important for Rock 5. Will it equally work for Orange Pi 5?

nyanmisaka commented 9 months ago

@hbiyik

but my panthor is completely broken.

Do you mean adding these mpp related code prevents panthor from running?

I am not sure it is easy, because mpp is using alot of extra exported symbols from iommu_rockchip and someother variants of rockchip drivers. This should never be allowed in mainline. One option would be to use existing kernel interfaces to do similar operations but i am not that good at kernel development. I think the reason for mpp doing this is that, since it is controlled by user space sometimes it needs to reset itself and some other systems like mmu. You can see those operation in the history log, where i have cherry picked some commits from vendor kernel.

Indeed. We shouldn't waste time on DKMS at this early stage.

Should be, because mainline is not the best when it comes to opp_select, pvtm, especially on the clock driver. The clock driver was very different than the vendor, i am not sure it is better or worse but the commit history was even completely different.

Mainline is not mature in frequency scaling, even though collabora has a custom cpufreq driver. An example is that the lowest CPU freq in bsp can be reduced to 400Mhz versus 800Mhz in mainline.

nyanmisaka commented 9 months ago

@nyanmisaka @hbiyik can you guys please enlighten me about what's going on with panthor? Is it better than panfork? How is it related to panfrost? :)

I understand you are doing something important for Rock 5. Will it equally work for Orange Pi 5?

Panthor is still in WIP and may take a few months to complete. We are trying it to prepare for transplanting MPP and RGA to mainline.

JM: job manager based scheduling CSF: firmware based scheduling

kernel mode: (linux kernel)

user mode: (mesa)

These efforts are not made for a specific board, but for all rk3588 based platforms.

nyanmisaka commented 9 months ago

https://github.com/nyanmisaka/linux-rockchip/commit/7e91bfc9fca6c85e87e2bd58b8e6aded5063a4c1

It seems the PCIe ASPM is controlled by setting supports-clkreq for pcie3x4: pcie@fe150000. @hbiyik This may help lowering the temperature of the NVME drive.

hbiyik commented 9 months ago

@nyanmisaka i enabled the ASPM but this thing is still hover 45~55 +-5C. I think this HW is designed to run hot, i also scrapped it from a dead laptop, and it (the NVME) was half burned anyways, so it is ok let it burn i dont care :)

Do you mean adding these mpp related code prevents panthor from running?

This i do not know, but i dont expect so, therefore i will wait a stable panthor to work on to troubleshoot efficiently, but it seems that it is not too hard to port mpp ot rga to mainline.

kyak commented 9 months ago

Just a heads up: kodi seems to be broken (horizontal lines/tear when scrolling) after this pull request: https://github.com/xbmc/xbmc/pull/23921

Can someone confirm?

hbiyik commented 9 months ago

@kyak i will check can you send a screenshot for me to compare.

Actually this pr in kodi was supposed to nake thinfs faster, i was following it.

kyak commented 9 months ago

@kyak i will check can you send a screenshot for me to compare.

Actually this pr in kodi was supposed to nake thinfs faster, i was following it.

Not sure how to make screenshot (technically).

But this problem is not screenshotable anyway. Tearing and lines happen when scrolling, then it's back to normal.

hbiyik commented 9 months ago

@kyak fixed in panfork, https://github.com/7Ji-PKGBUILDs/mesa-panfork-git/commit/bc05b90fbd3c77526aca1db0f02e2998cf5048dc, i think answers why we are trying panthor :) panfork is good, but people pissed off its developer, and he is no longer maintaining it.

kyak commented 9 months ago

@kyak fixed in panfork, 7Ji-PKGBUILDs/mesa-panfork-git@bc05b90, i think answers why we are trying panthor :) panfork is good, but people pissed off its developer, and he is no longer maintaining it.

Thanks a lot! I confirm that the problem is fixed.

sielicki commented 9 months ago

@nyanmisaka

first steps on the moon

[alarm@alarm ~]$ uname -a
Linux alarm 6.7.0-rc1-panthor-g4a610b4a1e08 #1 SMP PREEMPT Sat Nov 18 19:44:55 UTC 2023 aarch64 GNU/Linux
[alarm@alarm ~]$ ls /dev/mpp_service 
/dev/mpp_service

branch no longer exists, can you possibly post patches and/or repush this branch? I'm interested in headless decodes and want to play around with this.

nyanmisaka commented 9 months ago

@sielicki

https://github.com/hbiyik/linux/tree/panthor+mpp+rga

https://github.com/JeffyCN/FFmpeg/issues/18#issuecomment-1826926703

kyak commented 7 months ago

@hbiyik i'm getting black screen on all videos with exp_refactor_all branch. It started after a recent update, but i can't pinpoint exact packages.. Do you have any idea?

There has been your recent commit to the master branch. Maybe it also needs to go to exp_refactor_all branch?

hbiyik commented 7 months ago

Yeah i know the reason why, ill push a fix tonight, but you can better switch to ffmpeg-rockchip

kyak commented 7 months ago

Yeah i know the reason why, ill push a fix tonight, but you can better switch to ffmpeg-rockchip

Should I switch to ffmpeg-rockchip even though I'm using kernel 5.10?

kyak commented 7 months ago

I've tried ffmpeg-rockchip and it displays green screen on SD videos. Just like ffmpeg-mpp master (without the exp-refactor-all patches).

hbiyik commented 7 months ago

U should use direct rendering to plane but those also require some kernel and kodi patches

kyak commented 7 months ago

Indeed, cherry-picking 65f90322bf7413c47c25bcb3e53022a9109717d8 on top of exp_refactor_all has fixed the black screen issue.

kyak commented 7 months ago

U should use direct rendering to plane but those also require some kernel and kodi patches

I use direct rendering to plane, but kernel is 5.10.160-r1080192-695850f9bde2-ced0156-1-aarch64-orangepi5-git+ and kodi is Git:20240127-41c4a59fc31 built with external ffmpeg (using exp_refactor_all as external ffmpeg by LD_LIBRARY_PATH).

hbiyik commented 7 months ago

Yep that was the fix

kyak commented 6 months ago

@hbiyik what is the recommended combination of ffmpeg, kodi and kernel packages for Orange Pi 5+ right now?

I'm currently at linux-aarch64-orangepi5-git (from 7Ji repo), kodi-ext-git (building myself) and ffmpeg with exp_refactor_all branch (building myself). I also point kodi at this custom ffmpeg. I also have ffmpeg-rockchip-git (from repo), but that's not used by Kodi.

It feels like I'm missing a chance to provide feedback to you while you are playing around with kernels and ffmpeg. I'm staying with something obsolete and irrelevant.

Please suggest what users need to do so that developers have the best feedback possible.

hbiyik commented 6 months ago

@kyak

thanks for bringing this up, definetely use

https://github.com/nyanmisaka/ffmpeg-rockchip

may this is the last message in this repo and i will make it read only.

I will also add a message to the repo frontpage why you should not use this anymore.

Please also have a look at https://github.com/hbiyik/ffmpeg-rockchip/wiki/Rendering

7ji repo, agr, arch, debian based things are all moving to the ffmpeg-rockchip and i will be contributing there.

As always feeedback makes the project stronger, and always well come.

See you on the other repo.