On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:> On 30/07/13 21:39, Christ-Jan Wijtmans wrote: >> Hi, my apologies if this is the wrong place to post this. >> I had the desire to turn on or off support for certain chipsets. >> Because i felt like the nouveau drivers are (relatively) quite large and >> depends on some kernel code that would only be used for certain chipsets. >> I will take some time this week to see how this is coded and if its >> possible but i just wanted a head sup opinion on you guys before i start >> wasting my time. >> > I'm not entirely sure if you're talking about the kernel module, ddx > (xf86-video-nouveau) or mesa. > > In either case, all three should be relatively easy to do, as normally > the generation specific code is divided. Not too sure if it's worth the > effort though > > * kernel module - 1.7 MiB, ~400KiB gzip > * ddx - ~200KiB > * mesa - 6.3 MiB (nouveau/gallium only) > > As you can see the sizes are not that big, and I'm not sure if the > maintainers would be up-to the idea > > Not a maintainer myself so take the last statement if a healthy pinch of > salt :)I'm not a maintainer either, but to provide an opposing opinion, I strongly support the notion of being able to select card generations to build support for. 1.7M of kernel code is huge. I don't even think it'd be that hard (at least for the kernel module and mesa, and I think there's a lot less value in doing it for the DDX). I think it might be as easy as some Makefile changes + a couple of ifdefs in the init code to do Y/N selects. Making it so that the additional functionality can be loaded on demand (i.e. Y/M/N) may be much trickier, to the point of it not being worth it for the additional complexity. -ilia
On 30/07/2013 18:43, Ilia Mirkin wrote:> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >> On 30/07/13 21:39, Christ-Jan Wijtmans wrote: >>> Hi, my apologies if this is the wrong place to post this. >>> I had the desire to turn on or off support for certain chipsets. >>> Because i felt like the nouveau drivers are (relatively) quite large and >>> depends on some kernel code that would only be used for certain chipsets. >>> I will take some time this week to see how this is coded and if its >>> possible but i just wanted a head sup opinion on you guys before i start >>> wasting my time. >>> >> I'm not entirely sure if you're talking about the kernel module, ddx >> (xf86-video-nouveau) or mesa. >> >> In either case, all three should be relatively easy to do, as normally >> the generation specific code is divided. Not too sure if it's worth the >> effort though >> >> * kernel module - 1.7 MiB, ~400KiB gzip >> * ddx - ~200KiB >> * mesa - 6.3 MiB (nouveau/gallium only) >> >> As you can see the sizes are not that big, and I'm not sure if the >> maintainers would be up-to the idea >> >> Not a maintainer myself so take the last statement if a healthy pinch of >> salt :) > I'm not a maintainer either, but to provide an opposing opinion, I > strongly support the notion of being able to select card generations > to build support for. 1.7M of kernel code is huge. I don't even think > it'd be that hard (at least for the kernel module and mesa, and I > think there's a lot less value in doing it for the DDX). I think it > might be as easy as some Makefile changes + a couple of ifdefs in the > init code to do Y/N selects. Making it so that the additional > functionality can be loaded on demand (i.e. Y/M/N) may be much > trickier, to the point of it not being worth it for the additional > complexity. > > -iliaIn mesa, it is possible to build the driver you want (nouveau_vieux, nv30, nv50 or nvc0) so the feature is already there. There is no point for the ddx. As for drm, I sure would use this feature as this would cut down compilation time a lot when doing out of the tree builds. With the core arch, in theory, it shouldn't be that hard if you want plan on using old cards only. However, if you plan on doing the opposite (drop old cards support), it is harder as newer cards still use code written for the old ones. If you like, you can draw a dependency map quite easily by looking into the device directory that will contain all the dependencies for every chipset. One more thing, maintaining these dependencies will be done poorly and eat development time. So I'm not in huge favour of this unless you introduce a system that only compiles code for chipsets up to a certain point (which is useless IMO).
On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres at free.fr> wrote:> On 30/07/2013 18:43, Ilia Mirkin wrote: >> >> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov at gmail.com> >> wrote: >>> >>> On 30/07/13 21:39, Christ-Jan Wijtmans wrote: >>>> >>>> Hi, my apologies if this is the wrong place to post this. >>>> I had the desire to turn on or off support for certain chipsets. >>>> Because i felt like the nouveau drivers are (relatively) quite large and >>>> depends on some kernel code that would only be used for certain >>>> chipsets. >>>> I will take some time this week to see how this is coded and if its >>>> possible but i just wanted a head sup opinion on you guys before i start >>>> wasting my time. >>>> >>> I'm not entirely sure if you're talking about the kernel module, ddx >>> (xf86-video-nouveau) or mesa. >>> >>> In either case, all three should be relatively easy to do, as normally >>> the generation specific code is divided. Not too sure if it's worth the >>> effort though >>> >>> * kernel module - 1.7 MiB, ~400KiB gzip >>> * ddx - ~200KiB >>> * mesa - 6.3 MiB (nouveau/gallium only) >>> >>> As you can see the sizes are not that big, and I'm not sure if the >>> maintainers would be up-to the idea >>> >>> Not a maintainer myself so take the last statement if a healthy pinch of >>> salt :) >> >> I'm not a maintainer either, but to provide an opposing opinion, I >> strongly support the notion of being able to select card generations >> to build support for. 1.7M of kernel code is huge. I don't even think >> it'd be that hard (at least for the kernel module and mesa, and I >> think there's a lot less value in doing it for the DDX). I think it >> might be as easy as some Makefile changes + a couple of ifdefs in the >> init code to do Y/N selects. Making it so that the additional >> functionality can be loaded on demand (i.e. Y/M/N) may be much >> trickier, to the point of it not being worth it for the additional >> complexity. >> >> -ilia > > > In mesa, it is possible to build the driver you want (nouveau_vieux, nv30, > nv50 or nvc0) so the feature is already there.Really? How do you compile only nv50? (Hint: you can't. nv30/nv50/nvc0 are all linked together in the nouveau driver, no way to split them out, largely because of the nouveau_drm_screen_create function.)> There is no point for the ddx. > > As for drm, I sure would use this feature as this would cut down compilation > time a lot when doing out of the tree builds. With the core arch, in theory, > it shouldn't be that hard if you want plan on using old cards only. However, > if you plan on doing the opposite (drop old cards support), it is harder > as newer cards still use code written for the old ones. If you like, > you can draw a dependency map quite easily by looking into the device > directory that will contain all the dependencies for every chipset. > > One more thing, maintaining these dependencies will be done poorly and > eat development time. So I'm not in huge favour of this unless you > introduce a system that only compiles code for chipsets up to a certain > point (which is useless IMO). > > > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau