Created attachment 125306 [details] screenshot running the thunar file manager on ARM64 using glamor acceleration When running debian on ARM64 we experience graphical artifacts when running 2D applications using glamor (EXA doesn't render any meaningful at all). I get the same corrutions running the modesetting-driver + glamor. The few OpenGL games I've tried worked fine (sauerbraten, chromium-bsu). Kernel: 4.1.8 Xorg: 1.18.3 Mesa 11.2.2 GPU: AMD Caicos
Created attachment 125307 [details] glxinfo output
Created attachment 125308 [details] kernel log
Except for the distortions rendering seems fine. I've uploaded a video to better illustrate the issue: https://www.youtube.com/watch?v=Fr-CQ2cHVbQ Regardless of the artifacts, 2D performance seems to be quite good: GtkPerf 0.40 - Starting testing: Thu Jun 30 18:53:34 2016 GtkEntry - time: 0.06 GtkComboBox - time: 0.69 GtkComboBoxEntry - time: 0.53 GtkSpinButton - time: 0.19 GtkProgressBar - time: 0.16 GtkToggleButton - time: 0.31 GtkCheckButton - time: 0.19 GtkRadioButton - time: 0.28 GtkTextView - Add text - time: 0.28 GtkTextView - Scroll - time: 0.01 GtkDrawingArea - Lines - time: 7.91 GtkDrawingArea - Circles - time: 9.97 GtkDrawingArea - Text - time: 1.03 GtkDrawingArea - Pixbufs - time: 0.39
Please attach the corresponding Xorg log file. Looks like it could be a coherency issue with glamor's vertex data. Assuming newer kernel and/or Mesa don't help, can you try if setting the environment variable MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage" for the Xorg process (!) helps?
With MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage" everything works fine. Impressive, thanks a lot!
Does R600_DEBUG=nowc instead of MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage" help as well?
With nowc set the corruptions are still there, unfortunately. I'll give mesa 12.0.1 a try, the kernel version used is unfortunately fixed.
Mesa 12.0.1 exhibits the same behaviour. Quite interesting that the core profile version is reported as "0.0" and OpenGL is limited to 2.1. As debian put the libraries into /usr/lib/aarch64-linux-gnu/ I had to configure it with: /configure --with-gallium-drivers=r600,radeonsi,nouveau --with-dri-drivers=swrast --enable-gallium-llvm --with-egl-platforms=drm --prefix=/usr --exec-prefix=/usr/lib/aarch64-linux-gnu --libdir=/usr/lib/aarch64-linux-gnu/
Created attachment 125335 [details] xorg.log of patched xserver with self-compiled mesa-12.0.1
Created attachment 125336 [details] glxinfo of self-compiled mesa-12 (reporting core-profile version 0.0)
You have to run Mesa configure with --enable-texture-float (blame the lawyers).
Thanks, with float textures it now correctly reports OpenGL-3.3 However more ugly things are going on. When running the PBO texture upload benchmark at available at http://www.songho.ca/opengl/gl_pbo.html, I get tons of the following messages: radeon: Failed to allocate a buffer: radeon: size : 4194304 bytes radeon: alignment : 4096 bytes radeon: domains : 2 radeon: flags : 4 radeon: Failed to allocate a buffer: radeon: size : 4194304 bytes radeon: alignment : 4096 bytes radeon: domains : 2 radeon: flags : 4 EE r600_texture.c:1346 r600_texture_transfer_map - failed to create temporary texture to hold untiled copy later on, when I try to resize the benchmark window, Xorg segfaults: Thread 1 "Xorg" received signal SIGSEGV, Segmentation fault. 0x0000ffffb6d59348 in evergreen_emit_constant_buffers (rctx=0xaaaaaad5cbe0, state=0xaaaaaad5dba8, buffer_id_base=<optimized out>, reg_alu_constbuf_size=<optimized out>, reg_alu_const_cache=<optimized out>, pkt_flags=<optimized out>) at evergreen_state.c:1877 1877 va = rbuffer->gpu_address + cb->buffer_offset; (gdb) bt #0 0x0000ffffb6d59348 in evergreen_emit_constant_buffers (rctx=0xaaaaaad5cbe0, state=0xaaaaaad5dba8, buffer_id_base=<optimized out>, reg_alu_constbuf_size=<optimized out>, reg_alu_const_cache=<optimized out>, pkt_flags=<optimized out>) at evergreen_state.c:1877 #1 0x0000ffffb6d86ab0 in r600_emit_atom (atom=0xaaaaaad5dba8, rctx=0xaaaaaad5cbe0) at r600_pipe.h:549 #2 r600_draw_vbo (ctx=0xaaaaaad5cbe0, dinfo=<optimized out>) at r600_state_common.c:1794 #3 0x0000ffffb6be30f0 in u_vbuf_draw_vbo (mgr=0xaaaaaadb1b60, info=<optimized out>) at util/u_vbuf.c:1163 #4 0x0000ffffb6a4e104 in st_draw_vbo (ctx=0xffffb3647010, prims=<optimized out>, nr_prims=1, ib=0x0, index_bounds_valid=<optimized out>, min_index=0, max_index=0, tfb_vertcount=0x0, stream=0, indirect=0x0) at state_tracker/st_draw.c:251 #5 0x0000ffffb6a17b04 in vbo_draw_arrays (ctx=0xffffb3647010, mode=5, start=0, count=4, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:503 #6 0x0000ffffb7290154 in glamor_poly_fill_rect_gl (prect=<optimized out>, nrect=1, gc=0xaaaaab8415cc, drawable=0xaaaaab833fc0) at ../../glamor/glamor_rects.c:128 #7 glamor_poly_fill_rect (drawable=0xaaaaab833fc0, gc=0xaaaaab8415cc, nrect=1, prect=<optimized out>) at ../../glamor/glamor_rects.c:163 #8 0x0000aaaaaabeccdc in damagePolyFillRect (pDrawable=0xaaaaab833fc0, pGC=0xaaaaab817ea0, nRects=1, pRects=<optimized out>) at ../../../miext/damage/damage.c:1194 #9 0x0000aaaaaaafe180 in ProcPolyFillRectangle (client=0xaaaaaacd1dc0) at ../../dix/dispatch.c:1883 #10 0x0000aaaaaab01d4c in Dispatch () at ../../dix/dispatch.c:430 #11 0x0000aaaaaab05c20 in dix_main (argc=1, argv=0xfffffffffc58, envp=<optimized out>) at ../../dix/main.c:300 #12 0x0000ffffb7a9c8a4 in __libc_start_main (main=0x0, argc=0, argv=0x0, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at libc-start.c:291 #13 0x0000aaaaaaaefba8 in _start ()
ok, there seem to be problems with TTM or DRM - running the same benchmark on nouveau also leads to an abort caused by issues with buffer allocation: [ 236.977333] [TTM] nouveau 0000:01:00.0: Unable to get page 0 [ 236.982990] [TTM] nouveau 0000:01:00.0: Failed to fill cached pool (r:-12)! Impressive, despite those low-level issues, both r600 as well as nouveau can run sauerbraten and glamor.
I was able to track the TTM issues down to a very small coherent dma memory pool setting (4MB). With the kernel options "coherent_pool=128M cma=256M" all the code stressing texture up-/download works fine at expected performance. I'll give it a try next week to see whether this also fixes the issues with GL_ARB_buffer_storage.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/591.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.