[Intel-gfx] [PATCH 1/5] drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"

[Jason Ekstrand]

On Thu, Jun 3, 2021 at 3:22 AM Daniel Vetter <daniel at ffwll.ch> wrote:
>
> On Wed, Jun 02, 2021 at 11:41:45AM -0500, Jason Ekstrand wrote:
> > This reverts 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser").  The
> > justification for this commit in the git history was a vague comment
> > about getting it out from under the struct_mutex.  While this may
> > improve perf for some workloads on Gen7 platforms where we rely on the
> > command parser for features such as indirect rendering, no numbers were
> > provided to prove such an improvement.  It claims to closed two
> > gitlab/bugzilla issues but with no explanation whatsoever as to why or
> > what bug it's fixing.
> >
> > Meanwhile, by moving command parsing off to an async callback, it leaves
> > us with a problem of what to do on error.  When things were synchronous,
> > EXECBUFFER2 would fail with an error code if parsing failed.  When
> > moving it to async, we needed another way to handle that error and the
> > solution employed was to set an error on the dma_fence and then trust
> > that said error gets propagated to the client eventually.  Moving back
> > to synchronous will help us untangle the fence error propagation mess.
> >
> > This also reverts most of 0edbb9ba1bfe ("drm/i915: Move cmd parser
> > pinning to execbuffer") which is a refactor of some of our allocation
> > paths for asynchronous parsing.  Now that everything is synchronous, we
> > don't need it.
> >
> > Signed-off-by: Jason Ekstrand <jason at jlekstrand.net>
> > Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > Reviewed-by: Jon Bloomfield <jon.bloomfield at intel.com>
>
> This needs the same Cc: stable and Fixes: lines as the dma_fence error
> propagation revert. Otherwise the cmd parser breaks, which isn't great.

Done.  I may have to create multiple versions of this patch for Greg
but I can do that.