[Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast

[Chris Wilson]

On Wed, Apr 05, 2017 at 11:11:38AM -0700, Jason Ekstrand wrote:
>    On Wed, Apr 5, 2017 at 11:03 AM, Emil Velikov
>    <[1]emil.l.velikov at gmail.com> wrote:
> 
>      On 5 April 2017 at 18:55, Daniel Vetter <[2]daniel at ffwll.ch> wrote:
>      > On Wed, Apr 05, 2017 at 04:38:25PM +0100, Emil Velikov wrote:
>      >> Hi Ken,
>      >>
>      >> On 5 April 2017 at 01:09, Kenneth Graunke <[3]kenneth at whitecape.org>
>      wrote:
>      >> > Hello,
>      >> >
>      >> > This series imports libdrm_intel into the i965 driver, hacks and
>      >> > slashes it down to size, and greatly simplifies our relocation
>      >> > handling.
>      >> >
>      >> > Some of the patches may be held for moderation.  You can find the
>      >> > series in git here:
>      >> >
>      >> > [4]https://cgit.freedesktop.org/~kwg/mesa/log/?h=bacondrm
>      >> >
>      >> > A couple of us have been talking about this in person and IRC for
>      >> > a while, but I realize I haven't mentioned anything about it on the
>      >> > mailing list yet, so this may come as a bit of a surprise.
>      >> >
>      >> > libdrm_intel is about 15 source files and almost 13,000 lines of
>      code.
>      >> > This series adds 3 files (one .c, two .h) and only 2,137 lines of
>      code:
>      >> >
>      >> >     60 files changed, 2784 insertions(+), 647 deletions(-)
>      >> >
>      >> > The rest of the library is basically useless to us.  It contains a
>      lot
>      >> > of legacy cruft from the pre-GEM, DRI1, or 8xx/9xx era.  But even
>      the
>      >> > parts we do use are in bad shape.  BO offset tracking is
>      non-threadsafe.
>      >> > Relocation handling is way too complicated.  These things waste
>      memory,
>      >> > burn CPU time, and make it difficult for us to take advantage of
>      new
>      >> > kernel features like I915_EXEC_NO_RELOC which would reduce overhead
>      >> > further.  The unsynchronized mapping API performs a synchronized
>      mapping
>      >> > on non-LLC platforms, which can massively hurt performance on
>      Atoms.
>      >> > Mesa is also using uncached GTT mappings for almost everything on
>      Atoms,
>      >> > rather than fast CPU or WC maps where possible.
>      >> >
>      >> > Evolving this code in libdrm is very painful, as we aren't allowed
>      to
>      >> > break the ABI.  All the legacy cruft and design mistakes (in
>      hindsight)
>      >> > make it difficult to follow what's going on.  We could keep piling
>      new
>      >> > layers on top, but that only makes it worse.  Furthermore, there's
>      a
>      >> > bunch of complexity that comes from defending against or supporting
>      >> > broken or badly designed callers.
>      >> >
>      >> I believe I mentioned it a few days ago - there is no need to worry
>      >> about API or ABI stability.
>      >>
>      >> Need new API - add it. Things getting fragile or too many layers -
>      sed
>      >> /libdrm_intel$(N)/libdrm_intel$(N+1)/ and rework as needed.
>      >>
>      >> I fear that Importing libdrm_intel will be detrimental to libva's
>      >> intel-driver, Beignet and xf86-video-intel
> 
>    I wouldn't worry about xf86-video-intel.  Chris has already copy+pasted
>    half of the X server, what's libdrm? :-)

Slight overexaggeration, but that libdrm_intel was snafu was the original
split.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre