iris: fix in fences backend for ext_external_objects edge case
This is based on a patch from Mario Kleiner and fixes the following edge case reported by him in MR!4337:
EXT_external_objects require we call glSignalSemaphoreEXT followed by a glFlush. If the rendering workload is small when Signal and Flush take place the relevant batch buffers with the actual rendering might have been submitted already. In that case the following condition is met: (iris_batch_bytes_used(batch) == 0). This causes: glFlush() --> iris_fence_flush() -> iris_batch_flush() -> _iris_batch_flush() to no-op, and so the fence doesn't get submitted to the kernel. Then when anv tries to submit an execuf2 that must wait on the shared VkSempahore / drm_syncobj fence, there isn't one and the kernel rejects the batchbuffer causing an -EINVAL return of the execbuf2 ioctl and a VK_DEVICE_LOST error.
Empty batch buffers do have typically one fence attached, but the ones carrying the extra fence from a glSignalSempahore() call do have at least 2.
Authored-by: Mario Kleiner mario.kleiner.de@gmail.com Signed-off-by: Eleni Maria Stea elene.mst@gmail.com