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

[Rob Clark]

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?

I believe, at least for egl fences (less sure about glx), it would be
possible to not have the restriction that driver must be able to flush
a fence without a context.  And for the context-bound case, passing an
optional pipe_context to fence_finish() (ie. NULL if no ctx bound)
would be sufficient:

"
    If the sync object being blocked upon will not be signaled in finite
    time (for example, by an associated fence command issued previously,
    but not yet flushed to the graphics pipeline), then
    eglClientWaitSyncKHR may wait forever. To help prevent this behavior
    (footnote1), if the EGL_SYNC_FLUSH_COMMANDS_BIT_KHR bit is set in
    <flags>, and <sync> is unsignaled when eglClientWaitSyncKHR is
    called, then the equivalent of Flush() will be performed for the
    current API context (i.e., the context returned by
    eglGetCurrentContext()) before blocking on <sync>. If no context is
    current for the bound API, the EGL_SYNC_FLUSH_COMMANDS_BIT_KHR bit
    is ignored.
"

BR,
-R