Hi Ken, On 5 April 2017 at 01:09, Kenneth Graunke <kenn...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev