<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 5, 2017 at 11:03 AM, Emil Velikov <span dir="ltr"><<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 5 April 2017 at 18:55, Daniel Vetter <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> wrote:<br>
> On Wed, Apr 05, 2017 at 04:38:25PM +0100, Emil Velikov wrote:<br>
>> Hi Ken,<br>
>><br>
>> On 5 April 2017 at 01:09, Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > This series imports libdrm_intel into the i965 driver, hacks and<br>
>> > slashes it down to size, and greatly simplifies our relocation<br>
>> > handling.<br>
>> ><br>
>> > Some of the patches may be held for moderation.  You can find the<br>
>> > series in git here:<br>
>> ><br>
>> > <a href="https://cgit.freedesktop.org/~kwg/mesa/log/?h=bacondrm" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/~<wbr>kwg/mesa/log/?h=bacondrm</a><br>
>> ><br>
>> > A couple of us have been talking about this in person and IRC for<br>
>> > a while, but I realize I haven't mentioned anything about it on the<br>
>> > mailing list yet, so this may come as a bit of a surprise.<br>
>> ><br>
>> > libdrm_intel is about 15 source files and almost 13,000 lines of code.<br>
>> > This series adds 3 files (one .c, two .h) and only 2,137 lines of code:<br>
>> ><br>
>> >     60 files changed, 2784 insertions(+), 647 deletions(-)<br>
>> ><br>
>> > The rest of the library is basically useless to us.  It contains a lot<br>
>> > of legacy cruft from the pre-GEM, DRI1, or 8xx/9xx era.  But even the<br>
>> > parts we do use are in bad shape.  BO offset tracking is non-threadsafe.<br>
>> > Relocation handling is way too complicated.  These things waste memory,<br>
>> > burn CPU time, and make it difficult for us to take advantage of new<br>
>> > kernel features like I915_EXEC_NO_RELOC which would reduce overhead<br>
>> > further.  The unsynchronized mapping API performs a synchronized mapping<br>
>> > on non-LLC platforms, which can massively hurt performance on Atoms.<br>
>> > Mesa is also using uncached GTT mappings for almost everything on Atoms,<br>
>> > rather than fast CPU or WC maps where possible.<br>
>> ><br>
>> > Evolving this code in libdrm is very painful, as we aren't allowed to<br>
>> > break the ABI.  All the legacy cruft and design mistakes (in hindsight)<br>
>> > make it difficult to follow what's going on.  We could keep piling new<br>
>> > layers on top, but that only makes it worse.  Furthermore, there's a<br>
>> > bunch of complexity that comes from defending against or supporting<br>
>> > broken or badly designed callers.<br>
>> ><br>
>> I believe I mentioned it a few days ago - there is no need to worry<br>
>> about API or ABI stability.<br>
>><br>
>> Need new API - add it. Things getting fragile or too many layers - sed<br>
>> /libdrm_intel$(N)/libdrm_<wbr>intel$(N+1)/ and rework as needed.<br>
>><br>
>> I fear that Importing libdrm_intel will be detrimental to libva's<br>
>> intel-driver, Beignet and xf86-video-intel</div></div></blockquote><div><br></div><div>I wouldn't worry about xf86-video-intel.  Chris has already copy+pasted half of the X server, what's libdrm? :-)<br><br></div><div>The others, yeah, they could possibly benefit from drm_intel3.  That said, I think you significantly over-estimate how much a driver actually gets from libdrm.  We chose to not use libdrm in Vulkan and it really hasn't caused us all that much pain.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"> >> development.<br>
>> Those teams seem to be more resource contained than Mesa, thus they<br>
>> will trail behind even more.<br>
>><br>
>> As an example - the intel-driver is missing some trivial winsys<br>
>> optimisations that landed in Mesa 3+ years ago. That could have been<br>
>> avoided if the helpers were shared with the help of<br>
>> libdrm_intel/other.<br></div></div></blockquote><div><br></div><div>libdrm should *never* touch winsys.  Please, no.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
> That is kinda the longer-term goal with this. There's a lot more that<br>
> needs to be done besides Ken's series here, this is just the first step,<br>
> but in the end we'll probably move brw_batch back into libdrm_intel2 or<br>
> so, for consumption by beignet and libva.<br>
><br>
> But for rewriting the world and getting rid of 10+ years of compat<br>
> garbage, having a split between libdrm and mesa isn't great.<br>
><br>
</div></div>So the goal is to have the code in mesa as a form of incubator until<br>
it reaches maturity.<br>
This way one will have a more rapid development and greater<br>
flexibility during that stage.<br></blockquote><div><br></div><div>Yes, I think we'd eventually like to have some shared code again.  However, at the moment, that code sharing is costing us dearly and it's time for a step back and a complete re-evaluation of how we do things.  Once we've settled on something we like then maybe we can consider sharing again.  Ideally, I'd like the Vulkan driver to be able to share at least some bits with i965.  At the moment, however, we don't know what the new API should look like or what bets we even want to share, so pulling the whole thing in is the right next step. <br></div></div></div></div>