3588解码jpeg问题

[yulinchenhades]

我用3588，有16G内存，测试的时候先读取1000张4k的图片(3840*2160)，为了避免拷贝，我直接缓存了mppframe，组成数组，然后在循环这个mppframe数组取出数据保存成jpg，我发现前面的341张都是正常的，但是之后保存的图片都是绿色的，这个可能是什么原因引起的，341张粗略计算下大概是花了4G的mppbuffer，难道是只能缓存4G空间的mppframe数据吗

[HermanChen]

是不是 32 位的程序，4G 的虚地址空间用完了？用 64 位程序试试

[yulinchenhades]

是不是 32 位的程序，4G 的虚地址空间用完了？用 64 位程序试试

不是，uname -m显示是aarch64，在系统上编译的，32位程序的只能用4G内存，我能缓存1000张4k的mppframe，肯定用了10几G了。我解码图片成mppframe的时候都没报错，把mppframe拿出后保存成图片才发现341张后的图片都是绿色。我把这1000张转成1080p，然后用同样的程序去处理，输出的图片就是正常的

[nyanmisaka]

@HermanChen I also encountered this bug. Even on boards with more than 4G of memory, DRM and DMA-HEAP allocator can only allocate up to 4G, and an error will be reported if it exceeds. All binaries are aarch64 and dma32 flag is not enabled.

dmesg error if it exceeds 4G:

[132327.379503] [drm:rockchip_gem_iommu_map] *ERROR* out of I/O virtual memory: -28

Is this a hardware limitation?

file librockchip_mpp.so.0
librockchip_mpp.so.0: ELF 64-bit LSB shared object, ARM aarch64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=fc9b574d389e7691ce9e21a4d4d320f11140ffb7, stripped

file ffmpeg
ffmpeg: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=a59b517dad4236153b80987cdba0fe3db080dbf3, for GNU/Linux 3.7.0, stripped

uname -a
Linux nanopct6 6.1.43-legacy-rk35xx #48 SMP Sun Jan  7 07:21:37 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

[HermanChen]

The device iova space is only 4G. So if the dma-buf attach to device is over 4G then it may have error.
I will bring kernel guys in to check this issue.

[HermanChen]

The device iova space is only 4G. So if the dma-buf attach to device is over 4G then it may have error.
I will bring kernel guys in to check this issue.

[yulinchenhades]

The device iova space is only 4G. So if the dma-buf attach to device is over 4G then it may have error. I will bring kernel guys in to check this issue.

那是不是现在mpp buffer group最多只能分配4G的空间，超过4G的空间会有异常

[HermanChen]

分 buffer 的时候还好，就是给硬件使用的时候，硬件的 iommu_domain 的 iova 是 32bit 的，不断把 buffer import 到 iommu_domain 之后超上限了

[yulinchenhades]

分 buffer 的时候还好，就是给硬件使用的时候，硬件的 iommu_domain 的 iova 是 32bit 的，不断把 buffer import 到 iommu_domain 之后超上限了

分buffer也没什么效果吧，因为这个mpp buffer group使用量上去之后就一直占用内存，即使把mpp buffer给release也会一直占用内存，所以我分配buffer的时候特地使用mpp_buffer_group_usage判断是否使用了500M，超过了就分个mpp buffer group出来，然后使用mpp_buffer_group_unused检测去释放mpp buffer group，所以即使分buffer，只要buffer总的使用量超过4G，后面分出来的buffer在使用上就会有问题。

[HermanChen]

不是，分 buffer 的时候问题不大，板上有 8G 物理内存，超 4G 不是问题，buffer group 也不影响
是 buffer 在给内核驱动使用的时候，内核里的 iommu 给 buffer 建硬件访问用的 iova 表的时候，这个 iova 地址只有 32bit，总空间只有 4G

[yulinchenhades]

不是，分 buffer 的时候问题不大，板上有 8G 物理内存，超 4G 不是问题，buffer group 也不影响 是 buffer 在给内核驱动使用的时候，内核里的 iommu 给 buffer 建硬件访问用的 iova 表的时候，这个 iova 地址只有 32bit，总空间只有 4G

单个buffer超过4G肯定是不行的，因为iova的限制。但是我使用的方法是每500M切个buffer，保存mppframe，如果按你说的，应该也没问题，但是为什么只有4G的buffer空间保存的mppframe能解码jpg有效，其他buffer空间保存解码的mppframe最终图片都是绿色的呢

[HermanChen]

因为每次 buffer 导入 map 的时候需要去建 iova 表，建 iova 表的时间太长，为了优化目的，在使用完 buffer 之后不会去把 iova 表释放，就先缓存着，这样导致空间被占用着，一直累积下来，新的 buffer 再导入就失败了。

[nyanmisaka]

https://github.com/rockchip-linux/kernel/blob/604cec4004abe5a96c734f2fab7b74809d2d742f/drivers/gpu/drm/rockchip/rockchip_drm_gem.c#L35-L51

[yulinchenhades]

因为每次 buffer 导入 map 的时候需要去建 iova 表，建 iova 表的时间太长，为了优化目的，在使用完 buffer 之后不会去把 iova 表释放，就先缓存着，这样导致空间被占用着，一直累积下来，新的 buffer 再导入就失败了。

按这样子其实总的buffer group的使用量还是要限制在4G以内，如果达到4G，新申请的buffer是没办法做iova的，是没效果的。

[chencl9410]

0001-DEBUG-use-uncache-iova-map-for-RKJPEG.patch
此补丁针对jpeg编解码器使用iova改为uncache map形式，在硬件任务完成后直接将buffer unmap；后续的buffer可以继续import