Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Tue 04 Apr 2017, Kenneth Graunke wrote: > This series imports libdrm_intel into the i965 driver, hacks and > slashes it down to size, and greatly simplifies our relocation > handling. You did it! IT'S FINALLY HAPPENING!!! Thanks for taking the leap. > https://cgit.freedesktop.org/~kwg/mesa/log/?h=bacondrm Bacon. Yum... > 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. This is a great start. > 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. I've poked inside libdrm enough times that I volunteer to do some reviewing. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Wed, Apr 5, 2017 at 11:27 AM, Kristian Høgsberg wrote: > On Wed, Apr 5, 2017 at 11:11 AM, Jason Ekstrand wrote: >> On Wed, Apr 5, 2017 at 11:03 AM, Emil Velikov >> wrote: >>> >>> On 5 April 2017 at 18:55, Daniel Vetter 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 >>> >> 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 >> >> >> I wouldn't worry about xf86-video-intel. Chris has already copy+pasted half >> of the X server, what's libdrm? :-) >> >> 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. >> >>> >>> >> 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. >> >> >> libdrm should *never* touch winsys. Please, no. >> >>> >>> > >>> > 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. >> >> >> 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. > > Th
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Wednesday, April 5, 2017 5:10:15 AM PDT Chris Wilson wrote: > On Tue, Apr 04, 2017 at 05:09:50PM -0700, Kenneth Graunke wrote: > > 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. > > One thing I will mention is that I put a lot of effort into trying to > explain why brw_batch.c behaves as it does and how it expects the kernel > to behave in relation to itself. Those comments are probably more > valuable than the code contributions... > -Chris Yeah, you wrote a ton of good comments. I definitely want them. I'll add importing them to the TODO list... --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Wed, Apr 5, 2017 at 2:27 PM, Kristian Høgsberg wrote: > On Wed, Apr 5, 2017 at 11:11 AM, Jason Ekstrand wrote: >> On Wed, Apr 5, 2017 at 11:03 AM, Emil Velikov >> wrote: >>> >>> On 5 April 2017 at 18:55, Daniel Vetter 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 >>> >> 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 >> >> >> I wouldn't worry about xf86-video-intel. Chris has already copy+pasted half >> of the X server, what's libdrm? :-) >> >> 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. >> >>> >>> >> 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. >> >> >> libdrm should *never* touch winsys. Please, no. >> >>> >>> > >>> > 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. >> >> >> 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. > > The
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Wed, Apr 5, 2017 at 11:11 AM, Jason Ekstrand wrote: > On Wed, Apr 5, 2017 at 11:03 AM, Emil Velikov > wrote: >> >> On 5 April 2017 at 18:55, Daniel Vetter 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 >> >> 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 > > > I wouldn't worry about xf86-video-intel. Chris has already copy+pasted half > of the X server, what's libdrm? :-) > > 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. > >> >> >> 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. > > > libdrm should *never* touch winsys. Please, no. > >> >> > >> > 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. > > > 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. The concern about code quality of libva is valid, but there's much more code inside mesa that could be shared with libva to increase code quality than there is in libdrm. libva
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On 5 April 2017 at 19:16, Alex Deucher wrote: > On Wed, Apr 5, 2017 at 2:03 PM, Emil Velikov wrote: >> On 5 April 2017 at 18:55, Daniel Vetter 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 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
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
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
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Wed, Apr 5, 2017 at 2:03 PM, Emil Velikov wrote: > On 5 April 2017 at 18:55, Daniel Vetter 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 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 > 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. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Wed, Apr 5, 2017 at 11:03 AM, Emil Velikov wrote: > On 5 April 2017 at 18:55, Daniel Vetter 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 > 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 > I wouldn't worry about xf86-video-intel. Chris has already copy+pasted half of the X server, what's libdrm? :-) 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. > >> 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. > libdrm should *never* touch winsys. Please, no. > > > > 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. > 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On 5 April 2017 at 18:55, Daniel Vetter 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 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 idea is amazing. Silly me did not click while reading the summary email. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Wed, Apr 05, 2017 at 04:38:25PM +0100, Emil Velikov wrote: > Hi Ken, > > On 5 April 2017 at 01:09, Kenneth Graunke 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
Hi Ken, On 5 April 2017 at 01:09, Kenneth Graunke 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
Re: [Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
On Tue, Apr 04, 2017 at 05:09:50PM -0700, Kenneth Graunke wrote: > 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. One thing I will mention is that I put a lot of effort into trying to explain why brw_batch.c behaves as it does and how it expects the kernel to behave in relation to itself. Those comments are probably more valuable than the code contributions... -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
[Mesa-dev] [PATCH 00/53] i965: Eat libdrm_intel for breakfast
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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
