On 5 April 2017 at 19:16, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Wed, Apr 5, 2017 at 2:03 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 5 April 2017 at 18:55, Daniel Vetter <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 <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. >>> >>> That is kinda the longer-term goal with this. There's a lot more that >>> needs to be done besides Ken's series here, this is just the first step, >>> but in the end we'll probably move brw_batch back into libdrm_intel2 or >>> so, for consumption by beignet and libva. >>> >>> But for rewriting the world and getting rid of 10+ years of compat >>> garbage, having a split between libdrm and mesa isn't great. >>> >> So the goal is to have the code in mesa as a form of incubator until >> it reaches maturity. >> This way one will have a more rapid development and greater >> flexibility during that stage. >> >> If I misunderstood you correctly and the above sounds right - then the s/misunderstood/understood/
>> idea is amazing. >> Silly me did not click while reading the summary email. > > This is sort of indirectly what we did for radeon. We basically > abandoned libdrm_radeon in mesa and wrote our own winsys, then that, > more or less, because the basis for libdrm_amdgpu. > Heh, that would explain a few wtf moments I had while skimming through the radeon winsys/libdrm. Thanks for the correction and explanation gents! Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
