[Mesa-dev] swr: Context destruction needs to wait on fences

[Victor Moya del Barrio]

Still playing with OpenSWR and I found some issues with glmark2 when
running on a (OpenSWR originally intended) many core system.

glmark2 seems to enjoy creating and destroying GLX contexts without
destroying the 'screen' and OpenSWR doesn't seem to have tested such
scenarios.  The two related issues I found:

1) OpenSWR was hanging on fences after GLX context was destroyed because
previous fence SYNC tasks were not completed.  The swr_destroy() function
creates a couple of new fences (for the framebuffer I guess) and stops the
threads before these fences corresponding SYNC tasks can complete.  As the
fence is per screen, not per context, the new context get stucks at the
first attempt to wait on a fence. [for glmark2 a workaround was to use the
--reuse-context option]
2) OpenSWR was hanging when destroying the screen.  The
swr_destroy_screen() waits on any pending fences, but if the context was
already destroyed the threads are already dead too and because of 1) there
may be pending fences that will never complete.  If the context is supposed
to be destroyed before the screen destruction I'm not sure why there should
be a fence there anyway.  [for glmark2 the workaround was to kill glmark2
by hand]

The patch below seems to solve it.  Make swr_destroy() wait for all fences
before completing the destruction of the context.

diff --git a/src/gallium/drivers/swr/swr_context.cpp
b/src/gallium/drivers/swr/swr_context.cpp
index 15e60cd..02c6db6 100644
--- a/src/gallium/drivers/swr/swr_context.cpp
+++ b/src/gallium/drivers/swr/swr_context.cpp
@@ -315,6 +315,8 @@ swr_destroy(struct pipe_context *pipe)

 pipe_sampler_view_reference(&ctx->sampler_views[PIPE_SHADER_VERTEX][i],
NULL);
    }

+   swr_fence_finish(pipe->screen, NULL, screen->flush_fence, 0);
+
    if (ctx->swrContext)
       SwrDestroyContext(ctx->swrContext);

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160908/f96ba498/attachment.html>