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.veli...@gmail.com> wrote: > > On 5 April 2017 at 18:55, Daniel Vetter <[2]dan...@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]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: > >> > > >> > [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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev