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

[Bloomfield, Jon]

> -----Original Message-----
> From: Jason Ekstrand <jason at jlekstrand.net>
> Sent: Thursday, May 27, 2021 3:13 PM
> To: intel-gfx-trybot at lists.freedesktop.org
> Cc: Jason Ekstrand <jason at jlekstrand.net>; Maarten Lankhorst
> <maarten.lankhorst at linux.intel.com>; Bloomfield, Jon
> <jon.bloomfield at intel.com>
> Subject: [PATCH 1/5] drm/i915: Revert "drm/i915/gem: Asynchronous
> cmdparser"
> 
> 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>
> Cc: Jon Bloomfield <jon.bloomfield at intel.com>
> ---
Reviewed-by: Jon Bloomfield <jon.bloomfield at intel.com>