[Mesa-dev] [PATCH 1/2] gallium: add PIPE_FLUSH_DEFERRED

[Marek Olšák]

On Mon, Jul 18, 2016 at 3:55 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Mon, Jul 18, 2016 at 9:24 AM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Mon, Jul 18, 2016 at 2:25 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> On Mon, Jul 18, 2016 at 8:16 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>
>>>> There are 2 uses:
>>>> - Asynchronous flushing for multithreaded drivers.
>>>> - Return a fence without flushing (mid-command-buffer fence). The driver
>>>>   can defer flushing until fence_finish is called.
>>>
>>> This should also be useful to me when I get a chance to rebase the
>>> gallium bits of the egl fence-fd patchset.  I guess the one question
>>> is what the behaviour is in screen->fence_finish().  I think I have a
>>> solution for that in freedreno (if I end up going the
>>> flush-from-u_queue route, since I'd end up with enough locking to
>>> flush without a ctx), although maybe that isn't the most general
>>> solution for other drivers.  I wonder if we should add an optional
>>> pipe_context ptr to fence_finish() for the cases when there is a
>>> context bound?
>>>
>>> Either way, I guess we need a bit more documentation about that.  With
>>> that resolved, r-b
>>
>> The behavior of fence_finish isn't changed. The only side effect can
>> be that fence_finish will wait a little longer. No guidance is given
>> as to how drivers should implement fence_finish with deferred flushes.
>> If some drivers can't do deferred flushes safely, they should just
>> ignore the flag.
>
> ok, mind adding something to that effect to the gallium docs?

Yes, I've added that comment of mine. (and your rb)

Marek