This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mali T400 rendering speed limit with Wayland

Hi,

I am trying to find the practical limit of triangle / frames that the Mali T400 can render while keeping up at 60 FPS on a 1024x600 display with a Wayland integration on a ZynqMP+.

With the program and hardware setup described below, I could reach around 32 000 triangles per frame before performance dips below 60 FPS. This number is lower than I expected considering the "0.11 Mtriangles/sec/MHz" reported in the ZynqpMP+ datasheet (page 2). What steps could I take to render more triangles per frame?

To render as many triangle as possible, I reused the sample program "weston-simple-egl" from the Weston (wayland compositor) project. I changed the rendering to draw a fullscreen window (1024x600) with a GL_TRIANGLE_STRIP spanning around 95% of the screen. I tested the program with 32 bits per pix (bpp) and 16 bpp, but couldn't make any significant gain. The Mali GPU ont the system is clocked at 600MHz. The vertex and fragment shader are respectivly passing the vertices and the fragment as is.

The bottleneck seems to be the `eglSwapBuffers` call. It takes more and more time as the number of triangle rises. With 32 000 triangles, it can take up to 18 ms (!), which explains the FPS drop. Unfortunatly, eglSwapBuffers is implemented by the closed source library libmali, so I couldn't dig deeper. I assume the `eglSwapBuffers` call returns when an IRQ comes back from the GPU indicating that the queued jobs are done.

So, in summary, am I effectivly hitting an hardware limit at 32 000 triangles per frame under wayland or is there something I could do to improve performance?

Top replies

gchamp over 4 years ago in reply to gchamp +2 verified

To sort of give closure on this topic, I upgraded to linux 5.7 and switched to the lima open source drivers. Performance seems slightly better, particularly since dynamic heap memory management was implemented...

Parents

0 gchamp over 4 years ago in reply to p00chie

> So i think the driver should be ok. Maybe there is something missing the the drm or gpu?

I think you're right, everything seems initialized correctly in the logs.

> Does kmscube did work for you?

Yes it works. It seems you have the error "failed to set mode: Invalid argument". I think this is an issue with the buffer format kmscube uses by default. I have this patch locally for kmscube:

diff --git a/common.c b/common.c
index b6f3e9b..d772a79 100644
--- a/common.c
+++ b/common.c
@@ -43,7 +43,7 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
 const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier)
 {
        gbm.dev = gbm_create_device(drm_fd);
-       gbm.format = GBM_FORMAT_XRGB8888;
+       gbm.format = GBM_FORMAT_RGB565;
        gbm.surface = NULL;
 
        if (gbm_surface_create_with_modifiers) {

> But withing weston glmark2-es2-wayland failed with

> error: import buffer not properly aligned

> Can you start it?

It starts, but it's doesn't render correctly. The image doesn't render on screen. I have this patch in mesa also, which seems to be the cause of your crash:

Subject: [PATCH] lima: lima_resource: relax stride check

See https://gitlab.freedesktop.org/mesa/mesa/-/issues/3070

Suggested-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
 src/gallium/drivers/lima/lima_resource.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/lima/lima_resource.c b/src/gallium/drivers/lima/lima_resource.c
index 4644ea4..fd7614d 100644
--- a/src/gallium/drivers/lima/lima_resource.c
+++ b/src/gallium/drivers/lima/lima_resource.c
@@ -351,8 +351,21 @@ lima_resource_from_handle(struct pipe_screen *pscreen,
       stride = util_format_get_stride(pres->format, width);
       size = util_format_get_2d_size(pres->format, stride, height);
 
-      if (res->levels[0].stride != stride || res->bo->size < size) {
-         debug_error("import buffer not properly aligned\n");
+      if (res->tiled && res->levels[0].stride != stride) {
+         fprintf(stderr, "tiled imported buffer has mismatching stride: %d (BO) != %d (expected)",
+                     res->levels[0].stride, stride);
+         goto err_out;
+      }
+
+      if (!res->tiled && res->levels[0].stride < stride) {
+         fprintf(stderr, "linear imported buffer has mismatching stride: %d (BO) < %d (expected)",
+                     res->levels[0].stride, stride);
+         goto err_out;
+      }
+
+      if (res->bo->size < size) {
+         fprintf(stderr, "imported bo size is smaller than expected: %d (BO) < %d (expected)\n",
+                     res->bo->size, size);
          goto err_out;
       }
 
--

Weston has a few sample clients to test as well, such as "weston-simple-egl" that do work for me.

Reply