Hi Zhongmin, Michel,
On Thu, Jul 13, 2017 at 12:21 PM, Michel Dänzer <[email protected]> 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
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
