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

[Emil Velikov]

Hi Ken,

On 5 April 2017 at 01:09, Kenneth Graunke <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:
>
> 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 development.
Those teams seem to be more resource contained than Mesa, thus they
will trail behind even more.

As an example - the intel-driver is missing some trivial winsys
optimisations that landed in Mesa 3+ years ago. That could have been
avoided if the helpers were shared with the help of
libdrm_intel/other.

Just my 2c.
-Emil