Relative to version g6p0-01eac0-2, there are following important changes:
1. F: base/mali_base_submission_internal.h: 修复因为 BASE_CSF_CACHE_LINE_SIZE 定义为 uint32_t 导致按位算掩码的结果不符合预期问题
2. F: gles/src/draw/backend/mali_gles_draw_helpers_nx.cpp: 修复 创建texture table不销毁,导致的内存泄漏问题
3. rk_exts: x11: 扩展实现 egl_spec 定义的 "swap_interval 为 0" 行为
Actually updated libs:
lib/aarch64-linux-gnu/libmali-valhall-g610-g6p0-gbm.so
lib/aarch64-linux-gnu/libmali-valhall-g610-g6p0-wayland.so
lib/aarch64-linux-gnu/libmali-valhall-g610-g6p0-x11.so
lib/aarch64-linux-gnu/libmali-valhall-g610-g6p0-dummy.so
lib/aarch64-linux-gnu/libmali-valhall-g610-g6p0-dummy-gbm.so
Note that the last two libmalis were built with GCC 10.3.
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
Change-Id: Iae675fc68d6266baf86c49e4182b887581965313
Include followinig change:
rk_exts: wayland: 添加 egl_spec 定义的 "swap_interval 为 0" 行为
This could also fix the issue reported in https://redmine.rock-chips.com/issues/335131.
According to the back_trace when the app was stuck,
it's confirmed that get_window_target_buffer() in libmali was blocked in 'osu_sem_wait(&surf->buffer_limit);',
while the value of 'surf->buffer_limit' is 0.
The same stuck problem had been encountered and resolved
in the completed task "adding support for the case of swap_interval is 0", from which this commit comes.
The cause of the problem was that the original wayland/client/winsys/mali_egl_winsys.c
did not deal with buffer_release_event properly.
It was resolved by adding egl_winsys_surface::buffer_queue
and corresponding processes of handling events_for_buffers.
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
Change-Id: I4d4e2651114f221ffc0117b4a8166fa1b7cb8f02
We've bumped to midgard r18 and bifrost g2p0 for a long time.
Change-Id: Iaf8a688117ccdb23357aa067fb670f386dce2895
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Speed up normalize.sh and update_debian.sh.
Also remove the unneeded default libs.
Change-Id: I92745708496e28d5e2adfef24dfb4f5fd59c9f5e
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Compared to previous version, only libmalis with primary_winsys of x11 are changed.
Include following changes :
add platform_get_window for X11 eglCreatePlatformWindowSurfaceEXT()
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
Change-Id: Ibc0340ca709a10e50cf8d2cb395b25773eb2dbd1
The "3" at the end is "rk_so_ver".
It was reported by Jeffy Chen
that the patchelf, I used to process libs of libmali_for_356x_of_g2p0-01eac0-2,
is too old, resulting in building errors, such as :
root@Jeffy-Linux:/nvme/external/libmali/lib/aarch64-linux-gnu# aarch64-linux-gnu-strip libmali-bifrost-g52-g2p0.so
aarch64-linux-gnu-strip: stJK01Xo: not enough room for program headers, try linking with -N
aarch64-linux-gnu-strip:stJK01Xo[.note.gnu.build-id]: bad value
...
So, the libs of libmali_for_356x_of_g2p0-01eac0-3 were processed
by the patchelf provided by Jeffy Chen.
Change-Id: I0c321872efaa7a48fd57b075af631678d9be88ba
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
The "2" at the end is "rk_so_ver".
The full name of these libs is libmali-bifrost-g52-g2p0-dummy-gbm.so
"dummy-gbm" means that DUMMY is the primary_winsys, while GBM is also supported.
Some customers need this kind of libmali,
please refer to https://redmine.rock-chips.com/issues/290595.
The libs are including OpenCL implementation.
Change-Id: Ib7d379291d0949c10dc929d29d2b936b5cf97b0c
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
The "2" at the end is "rk_so_ver".
We could query this version info from binary file of libmali, such as :
strings libmali-bifrost-g52-g2p0-wayland.so | grep rk_so_ver
It would return:
arm_release_ver of this libmali is 'g2p0-01eac0', rk_so_ver is '2'.
The libs are including OpenCL implementation.
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
Change-Id: Ie7fe55ece977468ff7d45801fe1b2c31dc76f8a8
Other platforms are not ready yet.
Change-Id: I743834824761948a48e531d7f685dd5e07a8a1b1
Signed-off-by: huangds <hds@rock-chips.com>
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
