I’m trying to Port the GLMark2-ES Benchmark tool (for DRM flavour) on my RISC-V development board which is based on U740 CPU from SiFive, I’m able to successfully build and install from the Sources using the Meson build system, and don’t see any issue. But the problem arises when i’m trying to launch the compiled glmark2-es-drm program i’m facing issue with execution:
Though i’ve a GPU within my RISC-V SoC after execution of the program (glmark2-es-drm) i notice it is using the Mesa SW Pipeline over the CPU, and not over the Imagination GPU HW. (Log below…)
When tried to run the GLMark2-ES-DRM on Imagination GPU HW we’re observing that issue as the “XXX_dri.so: cannot open shared object file: No such file or directory”, can you please let us know on how we can generate the dri.so file to further execute the tests to using the Imagination GPU HW on our RISC-V Platform.
root@Ubuntu-riscv64:~# glmark2-es2-drm
MESA-LOADER: failed to open XXX: /usr/lib/dri/XXX_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/riscv64-linux-gnu/dri:\$${)
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/riscv64-linux-gnu/dri:\$)
MESA-LOADER: failed to open kms_swrast: /usr/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/riscv64-linu)
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/riscv64-linux-gnu/dr)
Error: Failed to create GBM device
Error: main: Could not initialize canvas
root@Ubuntu-riscv64:~#
After further debug we were able to link the other missing .so file, except the first xxx_dri.so file, Which is yet to resolve to run the GLMark2-ES benchmark on CPU, but unable to execute the same benchmark on GPU HW. Below is the log of the glmark2-es-drm output rendered over CPU using the Mesa Softpipe. Can you please help us to replicate the same using the IMG-GPU HW?
root@Ubuntu-riscv64:~/GL/glmark2# glmark2-es2-drm
MESA-LOADER: failed to open XXX: /usr/lib/dri/XXX_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/riscv64-linux-gnu/dri:\$${)
Warning: DRM_CAP_ASYNC_PAGE_FLIP not supported, falling back to 'mailbox' mode for SwapInterval(0).
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: Mesa
GL_RENDERER: softpipe
GL_VERSION: OpenGL ES 3.1 Mesa 23.2.1-1ubuntu3.1~22.04.2
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
Surface Size: 1080x1920 fullscreen
=======================================================
Please kindly do help on this, since we’re unable to get more support from GLMark2 further on this issue as they suspect it to be more issue on the GPU-SW Env Setup. Any inputs and support is highly appreciated.
Thanks for you’re message. We have built a own RISC-V Chip which is based on SiFive U74 CPU Core, and have bought and integrated IMG-GE8300 GPU IP. With which we are able to perform GPU Graphics Acceleration.
Thanks for the information. If your company has licensed the GPU IP directly from Imagination Technologies you should have an internal support email address directly at Imagination Technologies. Please write to that address explaining the problem. Otherwise, if your company is a customer of one of our customers, you can report to that customer asking for assistance (they will rely on the same internal support procedure to support you).
Thanks for you’re reply. Yes we did have the licensing of GPU IP from Imagination directly. But our support contract has expired recently (~month back), although we did try seek support with Imagination team with them while the support was active but was told it’s out of their scope of support to provide the support for GLMark2-ES. So we’d been looking into issue issue our-self.
We’re still in plan to enable the IMG-Support, but the timelines are unclear as when, So any suggestions here would be helpful for us to look at this issue even before the support is renewed… Please kindly do share us you’re thoughts on this. Thank you!
All the information I could find seems to point towards incompatibility between the libraries used to link the binary and the libraries at the target sysroot. Please try to use at link time the same libraries used in the sysroot where you are trying to run your binaries. Also please try to find out why there is a dependency with XXX_dri.so as it might be avoided.
We’ve a follow up update on this issue, We did get a Vision-Five 2 board (JH7100), and when trying to run the same GLMark2-ES-DRM application, We notice the app executes directly over the IMG-BXE4-32 GPU.
glmark2-es2-drm
=======================================================
glmark2 2021.02
=======================================================
OpenGL Information
GL_VENDOR: Imagination Technologies
GL_RENDERER: PowerVR B-Series BXE-4-32
GL_VERSION: OpenGL ES 3.2 build 1.19@6345021
=======================================================
Upon further check we noticed there is availability pvr_dri.so file, which is prompting the app to execute over GPU.
But the issue is we’re unable to locate the similar “pvr_dri.so” file on our RISC-V Development board even after building the DDK and loading the pvrsrvkm.ko module.
Can you please suggest here, what could be the issue here.?
I cannot tell without knowing in depth details what could be the cause of this issue. I recommend you try to build pvr_dri.so for your RISC-V development board and add it to the expected location, or use the version from the JH7100 board if it is compatible with the development board.
Thanks for your reply, I don’t think the pvr_dri.so would be fully compatible to run with our distribution or setup environment, as both the platforms have different GPU HW and are working on different Kernel.
So, it would be helpful if you can let us know or share details on building the pvr_dri.so file, So we can setup the same and verify on our environment. Thank you!
