[Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
Kenneth Graunke
kenneth at whitecape.org
Wed Apr 5 00:09:50 UTC 2017
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.
This series begins making incremental progress towards a better future
by importing libdrm_intel, and adjusting it to fit our needs. libdrm
provides some fairly foundational pieces of the driver, so it's not
easy to move away from it in one swoop. The series does not yet solve
most of the problems, but it does cut 85% of the code out, and removes
ABI-guarantee problems, which should make it much easier to work with.
I apologize that it may be difficult to review: most people aren't
familiar with this code (I learned a lot myself), and it's kind of
huge. I tried.
Thanks to Chris and Daniel for telling us to do this for years.
Thanks for Kristian and Emil for both independently trying to clean
up this mess in the past. Let's finally do it!
--Ken
More information about the mesa-dev
mailing list