[Mesa-dev] [EGL android: accquire fence implementation] i965: Queue the buffer with a sync fence for Android OS

[Tomasz Figa]

Hi Zhongmin, Michel,

On Thu, Jul 13, 2017 at 12:21 PM, Michel Dänzer <michel at daenzer.net> wrote:
> On 13/07/17 09:28 AM, Wu, Zhongmin wrote:
>> Hi Tomasz
>>
>> Thanks,  but I am afraid we have to use the last fence from the last buffer flushing , According to my understanding:
>>
>> If the glFlush was called before swapbuffer ,    there would be no new fence after that since the batch buffer may be flushed out, no batch flushing, no fence generated.
>>
>> ====
>> You can check the function "_intel_batchbuffer_flush_fence",  at the very beginning, it will check the content of the buffer, if it is empty, it will return and do nothing.
>> =====
>>
>> So, as the same reason,  it may not work if we use dri2_dpy->fence->create_fence_fd,   the process is below.
>>
>> Swapbuffer (==> flush batch buffer) ==>  create_fence_fd(===> flush batch buffer and get fd)
>>
>> You can see, the second buffer flushing may get nothing (not to mention  the first buffer flushing may get nothing either)

First of all, the sequence of calls is like this:

- brw_dri_create_fence_fd()
  - brw_fence_insert_locked()
    - brw_emit_mi_flush() <--- this emits commands to the command buffer...
    - intel_batchbuffer_flush_fence() <--- this should flush the
buffer and get a fence

but...

>
> Apologies for jumping into this discussion, and possibly missing some
> context.
>
> FWIW, it should be possible to re-use the previous fence when there is
> no new work to flush. See e.g. commits
>
> f1be3d8cdde1 ("radeonsi: don't flush an empty IB if the only thing we
>                need is a fence")
> 800efb0690e9 ("radeonsi: Flush when we're asked to return a fence but
>                don't have one yet")
>
> for how the radeonsi driver handles this.

I agree with Michel that it would make more sense if Intel driver kept
the last fence and returned it using when DRI2 fence extension is
called.

Best regards,
Tomasz