From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 97069] Radeon r600 glamor corruptions on ARM64
Date: Tue, 26 Jul 2016 01:03:51 +0000
Message-ID:
What
Removed
Added
Product
xorg
Mesa
Component
Driver/Radeon
Drivers/Gallium/radeonsi
Assignee
xorg-driver-ati@lists.x.org
dri-devel@lists.freedesktop.org
QA Contact
xorg-team@lists.x.org
dri-devel@lists.freedesktop.org
Version
unspecified
11.2
You are receiving this mail because:
=
--14694950310.1D91Deb6.11827--
--===============2084465706==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==
--===============2084465706==--
From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 97069] Radeon r600 glamor corruptions on ARM64
Date: Tue, 26 Jul 2016 01:04:22 +0000
Message-ID:
What
Removed
Added
Component
Drivers/Gallium/radeonsi
Drivers/Gallium/r600
You are receiving this mail because:
=
--14694950621.BcF2dbCcc.11829--
--===============0286027778==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==
--===============0286027778==--
From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 97069] Radeon r600 glamor corruptions on ARM64
Date: Tue, 26 Jul 2016 02:31:11 +0000
Message-ID: Does R600_DEBUG=3Dnowc instead of
MESA_EXTENSION_OVERRIDE=3D"-GL_ARB_buffer_storage" help as well?<=
/pre>
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&qu= ot; and OpenGL is limited to 2.1.=20 As debian put the libraries into /usr/lib/aarch64-linux-gnu/ I had to confi= gure it with: /configure --with-gallium-drivers=3Dr600,radeonsi,nouveau --with-dri-drivers=3Dswrast --enable-gallium-llvm --with-egl-platforms=3Ddr= m=20 --prefix=3D/usr --exec-prefix=3D/usr/lib/aarch64-linux-gnu --libdir=3D/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 (bl= ame 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/op= engl/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 tempora= ry 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=3D0xaaaaaad5cbe= 0, state=3D0xaaaaaad5dba8, buffer_id_base=3D<optimized out>, reg_alu_constbuf_size=3D<optimized out>, reg_alu_const_cache=3D&l= t;optimized out>, pkt_flags=3D<optimized out>) at evergreen_state.c:1877 1877 va =3D rbuffer->gpu_address + cb->buffer_offs= et; (gdb) bt #0 0x0000ffffb6d59348 in evergreen_emit_constant_buffers (rctx=3D0xaaaaaad= 5cbe0, state=3D0xaaaaaad5dba8, buffer_id_base=3D<optimized out>, reg_alu_constbuf_size=3D<optimized out>, reg_alu_const_cache=3D&l= t;optimized out>, pkt_flags=3D<optimized out>) at evergreen_state.c:1877 #1 0x0000ffffb6d86ab0 in r600_emit_atom (atom=3D0xaaaaaad5dba8, rctx=3D0xaaaaaad5cbe0) at r600_pipe.h:549 #2 r600_draw_vbo (ctx=3D0xaaaaaad5cbe0, dinfo=3D<optimized out>) at r600_state_common.c:1794 #3 0x0000ffffb6be30f0 in u_vbuf_draw_vbo (mgr=3D0xaaaaaadb1b60, info=3D<= ;optimized out>) at util/u_vbuf.c:1163 #4 0x0000ffffb6a4e104 in st_draw_vbo (ctx=3D0xffffb3647010, prims=3D<op= timized out>, nr_prims=3D1, ib=3D0x0, index_bounds_valid=3D<optimized out>= , min_index=3D0, max_index=3D0, tfb_vertcount=3D0x0, stream=3D0, indirect=3D0x0) at state_tracker/st_draw.c:251 #5 0x0000ffffb6a17b04 in vbo_draw_arrays (ctx=3D0xffffb3647010, mode=3D5, = start=3D0, count=3D4, numInstances=3D1, baseInstance=3D0) at vbo/vbo_exec_array.c:503 #6 0x0000ffffb7290154 in glamor_poly_fill_rect_gl (prect=3D<optimized o= ut>, nrect=3D1, gc=3D0xaaaaab8415cc, drawable=3D0xaaaaab833fc0) at ../../glamor/glamor_rects.c:128 #7 glamor_poly_fill_rect (drawable=3D0xaaaaab833fc0, gc=3D0xaaaaab8415cc, = nrect=3D1, prect=3D<optimized out>) at ../../glamor/glamor_rects.c:163 #8 0x0000aaaaaabeccdc in damagePolyFillRect (pDrawable=3D0xaaaaab833fc0, pGC=3D0xaaaaab817ea0, nRects=3D1, pRects=3D<optimized out>) at ../../../miext/damage/damage.c:1194 #9 0x0000aaaaaaafe180 in ProcPolyFillRectangle (client=3D0xaaaaaacd1dc0) at ../../dix/dispatch.c:1883 #10 0x0000aaaaaab01d4c in Dispatch () at ../../dix/dispatch.c:430 #11 0x0000aaaaaab05c20 in dix_main (argc=3D1, argv=3D0xfffffffffc58, envp=3D<optimized out>) at ../../dix/main.c:300 #12 0x0000ffffb7a9c8a4 in __libc_start_main (main=3D0x0, argc=3D0, argv=3D0= x0, init=3D<optimized out>, fini=3D<optimized out>, rtld_fini=3D<= ;optimized out>, stack_end=3D<optimized out>) at libc-start.c:291 #13 0x0000aaaaaaaefba8 in _start ()
ok, there seem to be problems with TTM or DRM - running the s= ame 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:-1= 2)! 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 cohere= nt dma memory pool setting (4MB). With the kernel options "coherent_pool=3D128M cma= =3D256M" 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.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- 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.