On Fri, Nov 07, 2014 at 04:52:25PM +0000, jfons...@vmware.com wrote:
> From: José Fonseca <jfons...@vmware.com>
>
Hi Jose,
This patch is causing random segfaults with OpenCL programs on radeonsi.
I haven't been able to figure out exactly what is happening, so I was
hoping you could help.
I think the problem has something to do with the fact that when clover
probes the hardware for OpenCL devices, the pipe_loader creates an
llvmpipe screen, checks the value of PIPE_CAP_COMPUTE, and then destroys
the screen since PIPE_CAP_COMPUTE is 0.
The only way I can reproduce this bug is by running the piglit OpenCL
tests concurrently. If it helps, here are the stack traces
from one of the core dumps I captured from a piglit run:
(gdb) thread 1
[Switching to thread 1 (Thread 0x7f6d53cdf700 (LWP 18653))]
#0 0x00007f6d53e56d2d in ?? ()
(gdb) bt
#0 0x00007f6d53e56d2d in ?? ()
#1 0x0000000000000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f6d5495f700 (LWP 18652))]
#0 0x00007f6d5aacd44c in pthread_cond_wait () from /lib64/libpthread.so.0
(gdb) bt
#0 0x00007f6d5aacd44c in pthread_cond_wait () from /lib64/libpthread.so.0
#1 0x00007f6d54c71dbb in mtx_init (mtx=0x7f6d54c71dbb <mtx_init+97>,type=0) at
../../../../../include/c11/threads_posix.h:182
#2 0x00007f6d54c72157 in radeon_set_fd_access
(applier=0x61e828,owner=0x61e800, mutex=0x7f6d54c71dbb <mtx_init+97>,
request=0,request_name=0x0, enable=238 '\356') at radeon_drm_winsys.c:70
#3 0x00007f6d54c7ad30 in radeon_drm_cs_emit_ioctl (param=0x61e4f0) at
radeon_drm_winsys.c:598
#4 0x00007f6d54c71ce0 in cnd_wait (cond=0x61e4f0, mtx=0x7f6d54c7ad07
<radeon_drm_cs_emit_ioctl+168>) at
../../../../../include/c11/threads_posix.h:152
#5 0x00007f6d5aac91da in start_thread () from /lib64/libpthread.so.0
#6 0x00007f6d5afd5d7d in clone () from /lib64/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 0x7f6d5c20c740 (LWP 18649))]
#0 0x00007f6d5afae73e in re_node_set_insert_last () from /lib64/libc.so.6
(gdb) bt
#0 0x00007f6d5afae73e in re_node_set_insert_last () from /lib64/libc.so.6
#1 0x00007f6d5afae7fe in register_state () from /lib64/libc.so.6
#2 0x00007f6d5afb1d39 in re_acquire_state_context () from /lib64/libc.so.6
#3 0x00007f6d5afbaa95 in re_compile_internal () from /lib64/libc.so.6
#4 0x00007f6d5afbb603 in regcomp () from /lib64/libc.so.6
#5 0x0000000000403e9b in regex_get_matches (src=0x63e6c0 "float",
pattern=0x40b940 "^ulong|ulong2|ulong3|ulong4|ulong8|ulong16$", pmatch=0x0,
size=0, cflags=4) at /home/tstellar/piglit/tests/cl/program/program-tester.c:476
#6 0x00000000004040e2 in regex_match (src=0x63e6c0 "float", pattern=0x40b940
"^ulong|ulong2|ulong3|ulong4|ulong8|ulong16$") at
/home/tstellar/piglit/tests/cl/program/program-tester.c:532
#7 0x00000000004059c6 in get_test_arg (src=0x63de70 "1 buffer float[7] 0.5
-0.5 0.0 -0.0 nan -3.99 1.5", test=0x645710, arg_in=true) at
/home/tstellar/piglit/tests/cl/program/program-tester.c:1016
#8 0x0000000000406f4a in parse_config ( config_str=0x63fe30
"\n[config]\nname: Test float trunc built-in on CL 1.1\nclc_version_min:
10\ndimensions: 1\n\n[test]\nname: trunc float1\nkernel_name:
test_1_trunc_float\nglobal_size: 7 0 0\n\narg_out: 0 buffer float[7] 0.0
-0.0"..., config=0x60e260 <config>) at
/home/tstellar/piglit/tests/cl/program/program-tester.c:1410
#9 0x00000000004074a7 in init (argc=2, argv=0x7fff46612d88, config=0x60e260
<config>) at /home/tstellar/piglit/tests/cl/program/program-tester.c:1555
#10 0x00007f6d5be0232c in piglit_cl_program_test_init (argc=2,
argv=0x7fff46612d88, void_config=0x60e260 <config>) at
/home/tstellar/piglit/tests/util/piglit-framework-cl-program.c:60
#11 0x00007f6d5be00f33 in piglit_cl_framework_run (argc=2, argv=0x7fff46612d88)
at /home/tstellar/piglit/tests/util/piglit-framework-cl.c:154
#12 0x0000000000403535 in main (argc=2, argv=0x7fff46612d88) at
/home/tstellar/piglit/tests/cl/program/program-tester.c:164
Thanks,
Tom
> On Windows, DllMain calls and thread creation/destruction are
> serialized, so when llvmpipe is destroyed from DllMain waiting for the
> rasterizer threads to finish will deadlock.
>
> So, instead of waiting for rasterizer threads to have finished, simply wait
> for the
> rasterizer threads to notify they are just about to finish.
>
> Verified with this very simple program:
>
> #include <windows.h>
> int main() {
> HMODULE hModule = LoadLibraryA("opengl32.dll");
> FreeLibrary(hModule);
> }
>
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=76252
>
> Cc: 10.2 10.3 <mesa-sta...@lists.freedesktop.org>
> ---
> src/gallium/drivers/llvmpipe/lp_rast.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
> b/src/gallium/drivers/llvmpipe/lp_rast.c
> index a3420a2..6b54d43 100644
> --- a/src/gallium/drivers/llvmpipe/lp_rast.c
> +++ b/src/gallium/drivers/llvmpipe/lp_rast.c
> @@ -800,6 +800,8 @@ static PIPE_THREAD_ROUTINE( thread_function, init_data )
> pipe_semaphore_signal(&task->work_done);
> }
>
> + pipe_semaphore_signal(&task->work_done);
> +
> return 0;
> }
>
> @@ -885,9 +887,11 @@ void lp_rast_destroy( struct lp_rasterizer *rast )
> pipe_semaphore_signal(&rast->tasks[i].work_ready);
> }
>
> - /* Wait for threads to terminate before cleaning up per-thread data */
> + /* Wait for threads to terminate before cleaning up per-thread data.
> + * We don't actually call pipe_thread_wait to avoid dead lock on Windows
> + * per https://bugs.freedesktop.org/show_bug.cgi?id=76252 */
> for (i = 0; i < rast->num_threads; i++) {
> - pipe_thread_wait(rast->threads[i]);
> + pipe_semaphore_wait(&rast->tasks[i].work_done);
> }
>
> /* Clean up per-thread data */
> --
> 1.9.1
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
