On Mon, Jul 18, 2016 at 3:55 PM, Rob Clark <robdcl...@gmail.com> wrote: > On Mon, Jul 18, 2016 at 9:24 AM, Marek Olšák <mar...@gmail.com> wrote: >> On Mon, Jul 18, 2016 at 2:25 PM, Rob Clark <robdcl...@gmail.com> wrote: >>> On Mon, Jul 18, 2016 at 8:16 AM, Marek Olšák <mar...@gmail.com> wrote: >>>> From: Marek Olšák <marek.ol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev