diff options
author | Tomasz Figa <[email protected]> | 2018-12-14 17:17:40 +0900 |
---|---|---|
committer | Roland Scheidegger <[email protected]> | 2019-01-09 02:06:13 +0100 |
commit | f6a6da8131383d8eeee07cd59326a70f4b15866b (patch) | |
tree | 2fadb24f203ae0ed474db79b84d1b63c906ced10 /src/amd/vulkan/radv_android.c | |
parent | 700aeaf9c863ea545fe529c1a7fcbc8e87c9adb4 (diff) |
llvmpipe: Always return some fence in flush (v2)
If there is no last fence, due to no rendering happening yet, just
create a new signaled fence and return it, to match the expectations of
the EGL sync fence API.
Fixes random "Could not create sync fence 0x3003" assertion failures from
Skia on Android, coming from the following code:
https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427
Reproducible especially with thread count >= 4.
One could make the driver always keep the reference to the last fence,
but:
- the driver seems to explicitly destroy the fence whenever a rendering
pass completes and changing that would require a significant functional
change to the code. (Specifically, in lp_scene_end_rasterization().)
- it still wouldn't solve the problem of an EGL sync fence being created
and waited on without any rendering happening at all, which is
also likely to happen with Android code pointed to in the commit.
Therefore, the simple approach of always creating a fence is taken,
similarly to other drivers, such as radeonsi.
Tested with piglit llvmpipe suite with no regressions and following
tests fixed:
egl_khr_fence_sync
conformance
eglclientwaitsynckhr_flag_sync_flush
eglclientwaitsynckhr_nonzero_timeout
eglclientwaitsynckhr_zero_timeout
eglcreatesynckhr_default_attributes
eglgetsyncattribkhr_invalid_attrib
eglgetsyncattribkhr_sync_status
v2:
- remove the useless lp_fence_reference() dance (Nicolai),
- explain why creating the dummy fence is the right approach.
Signed-off-by: Tomasz Figa <[email protected]>
Diffstat (limited to 'src/amd/vulkan/radv_android.c')
0 files changed, 0 insertions, 0 deletions