summaryrefslogtreecommitdiffstats
path: root/build-support
diff options
context:
space:
mode:
authorNicolai Hähnle <[email protected]>2017-11-09 14:00:22 +0100
committerNicolai Hähnle <[email protected]>2017-11-09 14:00:22 +0100
commite6dbc804a87aef34db138c607ba435d701703bc6 (patch)
tree72886d32739f09c9fdb41dce690b040994671f0c /build-support
parent1e5c9cf5902e31d3e038c565588527be35434306 (diff)
winsys/amdgpu: handle cs_add_fence_dependency for deferred/unsubmitted fences
The idea is to fix the following interleaving of operations that can arise from deferred fences: Thread 1 / Context 1 Thread 2 / Context 2 -------------------- -------------------- f = deferred flush <------- application-side synchronization -------> fence_server_sync(f) ... flush() flush() We will now stall in fence_server_sync until the flush of context 1 has completed. This scenario was unlikely to occur previously, because applications seem to be doing Thread 1 / Context 1 Thread 2 / Context 2 -------------------- -------------------- f = glFenceSync() glFlush() <------- application-side synchronization -------> glWaitSync(f) ... and indeed they probably *have* to use this ordering to avoid deadlocks in the GLX model, where all GL operations conceptually go through a single connection to the X server. However, it's less clear whether applications have to do this with other WSI (i.e. EGL). Besides, even this sequence of GL commands can be translated into the Gallium-level sequence outlined above when Gallium threading and asynchronous flushes are used. So it makes sense to be more robust. As a side effect, we no longer busy-wait on submission_in_progress. We won't enable asynchronous flushes on radeon, but add a cs_add_fence_dependency stub anyway to document the potential issue. Reviewed-by: Marek Olšák <[email protected]>
Diffstat (limited to 'build-support')
0 files changed, 0 insertions, 0 deletions